[OT] on wording of computer messages [was: Re: systemd fails to poweroff - "A stop job is running for Session 2 of user $USER"]

Zenaan Harkness zen at freedbms.net
Wed Aug 13 01:23:57 UTC 2014


On 8/13/14, Zenaan Harkness <zen at freedbms.net> wrote:
> On 8/13/14, Padraig Rocks <padraig.rocks at gmail.com> wrote:
>> On Tuesday, 12 August 2014, Andrei POPESCU <andreimpopescu at gmail.com>
>> wrote:
>>
>>> On Ma, 12 aug 14, 12:51:12, Paul E Condon wrote:
>>> > I interpret the quoted string in the Subject: header as being flawed
>>> > use of English language. 'stop' should be 'stopped'. And, there is a
>>> ...
>>> > In a better formulated message, there should be a comma ',' between
>>> > 'user' and '$USER'. Thus if the USER of Session 2 is Joe, the message
>>> > should read (adding a full stop at the end):
>>> >
>>> > "A stopped job is running for Session 2 of user, Joe."
>>> >
>>> > But even this is poorly worded. A job that is both running, and
>>> > stopped is a goofy idea, as well as somewhat verbose. Maybe it should
>>> > be:
>>> >
>>> > "A stopped job exists for Session 2 of user, Joe."
>>>
>>> As a non-native speaker of English I understood the message as being
>>> about a job that tries to stop something, hence "a stop job". Also, the
>>> comma definitely "feels" wrong. If anything that I'd rather put a colon,
>>> but it's still quite understandable for me like it is.
>>
>> Or to avoid the comma ?
>>
>> " A stopped job exists in Session 2 of the user named Joe"
>
> I too read the error as meaning a special noun/ special process or
> application called a "stop job".
>
> Often resequencing an English sentence can help to remove ambiguities, eg:
> For Session 2 of user joe, a stop job exists.
>
> Or of course if the word is meant to be stopped:
> For Session 2 of user joe, a stopped job exists.
>
> There should also be a suggestion in the error message of timeout eg:
> For Session 2 of user joe, a stop job exists; now waiting up to 90 seconds.

But really, there ought also be some hint as to what the job is,
perhaps a pointer to a line in the logs, since a process ID is not
very useful (unless it is still possible to log in to check that
process id?), or perhaps the "ps aux" type line for the process at
issue, that would go a long way to assisting users trying to debug
such things...

These things are of course obvious in hindsight, so perhaps such
suggestions can filter to the systemd devs?

Regards,
Zenaan



More information about the D-community-offtopic mailing list