subject:"A stop job is running for..."


On 12/02/2015 06:06 AM, Martin Read wrote:

The default and per-service timeout values for stopping a service (after
which systemd gives up and sends fatal signals to all of the service's
processes) are configurable; see the systemd-system.conf(5) and
systemd.service(5) man pages for details.




This could be useful. Time to wade into the man pages. I'm grateful.

Re: A stop job is running for...

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:

> On 02/12/15 03:07, James P. Wallen wrote:
> > Thanks for your response, Sven. It's nice to know that someone else
> > has seen this type of problem. I was thinking that this could be
> > self-inflicted. Perhaps that's a little less likely now.
> >
> > So, is this behavior controlled by systemd?
> >
> > I'm not trying to start a fracas. I'm really interested. What I'm
> > asking is, do I need to start poring over systemd documentation to
> > see if there might be a way to control this behavior?
>
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
>
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the systemd-system.conf(5)
> and systemd.service(5) man pages for details.

'scuse me, but shouldn't the errant process be fixed so it can stop and 
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: A stop job is running for...


On 12/02/2015 10:49 AM, David Wright wrote:

On Wed 02 Dec 2015 at 11:06:09 (+), Martin Read wrote:

On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the
systemd-system.conf(5) and systemd.service(5) man pages for details.


I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color Profiles 
(34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.

Cheers,
David.



Now *that* would be annoying.

It's interesting that I have been unable to find bug reports about this. 
I guess it might be kind of hard to figure which packages to file a 
report against. I can imagine there might be a bit of finger-pointing 
between the systemd folks and the developers and maintainers of the 
various packages services when unfortunate interactions via the service 
units are hard to tease out.


It is at least nice to have a way to force an errant service to shut 
down -- assuming the scheme works. I haven't experimented yet, but 
that's on the schedule for later today. I suppose it's unlikely that 
forcing a service like CUPS or NTP to shut down will lead to other 
problems. I hope.

Re: A stop job is running for...


On 12/02/2015 12:17 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:05 schrieb Jape Person:

On 12/02/2015 10:49 AM, David Wright wrote:

I have observed behaviour where, when the time limit of 90 seconds is
reached, the limit increases by another 90 seconds and nothing else
happens (for hours). eg

[ <*> ] A stop job is running for Manage, Install and Generate Color
Profiles (34min 54s / 36min)_

Fortunately, that hasn't happened for a few months. It's very
embarrassing when my laptop takes longer to close down than my
wife's W10.


Sounds like it could be hard to reproduce indeed.


Now *that* would be annoying.


In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT



Seven times. How lucky!

Heh.

Thank you, Michael.

Do you think it's better just force the shutdown than to rummage around 
in the service unit files? I'm loath to edit system configuration files 
unless it's to configure something like smartmontools or some such -- 
you know, something that is more ordinarily edited in order to get it to 
do some specific job.


I guess that argument could apply to service units, but I'm not used to 
this stuff, yet.


Thanks again,
JP

Re: A stop job is running for...

2015-12-02 Thread Michael Biebl

Am 02.12.2015 um 18:05 schrieb Jape Person:
> On 12/02/2015 10:49 AM, David Wright wrote:
>> I have observed behaviour where, when the time limit of 90 seconds is
>> reached, the limit increases by another 90 seconds and nothing else
>> happens (for hours). eg
>>
>> [ <*> ] A stop job is running for Manage, Install and Generate Color
>> Profiles (34min 54s / 36min)_
>>
>> Fortunately, that hasn't happened for a few months. It's very
>> embarrassing when my laptop takes longer to close down than my
>> wife's W10.

Sounds like it could be hard to reproduce indeed.

> Now *that* would be annoying.

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].

Regards,
Michael


http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...


On 12/02/2015 01:21 PM, Gene Heskett wrote:

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:


On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else
has seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm
asking is, do I need to start poring over systemd documentation to
see if there might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service
has one or more ExecStop lines defined in its service unit and that
one of those commands is taking an unduly long time to complete for
some reason.

The default and per-service timeout values for stopping a service
(after which systemd gives up and sends fatal signals to all of the
service's processes) are configurable; see the systemd-system.conf(5)
and systemd.service(5) man pages for details.


'scuse me, but shouldn't the errant process be fixed so it can stop and
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett



It's occurred to me that, though I have occasionally seen service 
shutown issues with sysv-init, they were never as pervasive or repetitve 
as it has been since switching to systemd as the init system. And the 
issue seems to be happening with several different types of services. 
That at least begs the question as to whether the problem is really with 
the services themselves or with the way they are controlled by systemd.


I'm guessing that this is just a sort of shakedown cruise problem, where 
it may be that those who develop and maintain some packages will have to 
customize those packages' service units to work properly with systemd OR 
that there are problems with systemd itself OR both.


Or maybe end users like me just need to learn to deal with systemd. 
However, the idea of having end users edit service units hardly seems 
like an ideal routine.


Regards,
JP

Re: A stop job is running for...

2015-12-02 Thread Michael Biebl

Am 02.12.2015 um 18:58 schrieb Jape Person:
> On 12/02/2015 12:17 PM, Michael Biebl wrote:
>> In case you run into such a situation again, where a service is blocking
>> the shutdown you can of course just use force and pull the plug or use
>> sysrq b.
>> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
>> systemd then will initiate a forced shutdown. See [1].

..

> Do you think it's better just force the shutdown than to rummage around
> in the service unit files? I'm loath to edit system configuration files
> unless it's to configure something like smartmontools or some such --
> you know, something that is more ordinarily edited in order to get it to
> do some specific job.
> 
> I guess that argument could apply to service units, but I'm not used to
> this stuff, yet.

In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.

My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: A stop job is running for...


On 12/02/2015 02:04 PM, Michael Biebl wrote:

Am 02.12.2015 um 18:58 schrieb Jape Person:

On 12/02/2015 12:17 PM, Michael Biebl wrote:

In case you run into such a situation again, where a service is blocking
the shutdown you can of course just use force and pull the plug or use
sysrq b.
But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
systemd then will initiate a forced shutdown. See [1].


..


Do you think it's better just force the shutdown than to rummage around
in the service unit files? I'm loath to edit system configuration files
unless it's to configure something like smartmontools or some such --
you know, something that is more ordinarily edited in order to get it to
do some specific job.

I guess that argument could apply to service units, but I'm not used to
this stuff, yet.


In your case it seems to happen much more often, that the service does
not shutdown in a timely manner. So this should actually be investigated
properly.



Aye, there's the rub!

The phrase "investigated properly" would seem to indicate that someone 
who knows what s/he's doing would be performing the analysis.


How about me doing my usual thumb-fingered job on it, and then coming 
back here for advice when I have enough bruises on my forehead to prove 
that I have indeed been to the wall?


;-)


My remark regarding using a forced shutdown via ctrl+alt+-del is only
supposed to be a fix for very rare cases.

I also wouldn't consider it a proper fix to simply decrease the shutdown
timeout of the affected service. That's a hack at best.

Michael




Yes, I was beginning to be dimly aware. I don't like futzing around with 
files in system or root owned areas unless they are designed to be 
futzed with. Not only because I don't like having my modifications 
overwritten during upgrades (and I do always choose to write the 
maintainer's upgrade over my modification and then change it again as 
necessary), but also because I don't like knowing that all sorts of 
weird stuff might happen if I do something particularly stupid.


I am, after all, very experienced and accomplished at being particularly 
stupid. It's why I run testing. I like having a plausible explanation, 
other than my own ineptitude, for having things go wrong.


Have a nice day!

JP

Re: A stop job is running for...

2015-12-02 Thread Don Armstrong

On Wed, 02 Dec 2015, Jape Person wrote:
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system.

This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.

If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.

-- 
Don Armstrong  http://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_

Re: A stop job is running for...

On Wednesday 02 December 2015 14:02:50 Jape Person wrote:

> On 12/02/2015 01:21 PM, Gene Heskett wrote:
> > On Wednesday 02 December 2015 06:06:09 Martin Read wrote:
> >> On 02/12/15 03:07, James P. Wallen wrote:
> >>> Thanks for your response, Sven. It's nice to know that someone
> >>> else has seen this type of problem. I was thinking that this could
> >>> be self-inflicted. Perhaps that's a little less likely now.
> >>>
> >>> So, is this behavior controlled by systemd?
> >>>
> >>> I'm not trying to start a fracas. I'm really interested. What I'm
> >>> asking is, do I need to start poring over systemd documentation to
> >>> see if there might be a way to control this behavior?
> >>
> >> If a stop job is taking two minutes, that suggests that the service
> >> has one or more ExecStop lines defined in its service unit and that
> >> one of those commands is taking an unduly long time to complete for
> >> some reason.
> >>
> >> The default and per-service timeout values for stopping a service
> >> (after which systemd gives up and sends fatal signals to all of the
> >> service's processes) are configurable; see the
> >> systemd-system.conf(5) and systemd.service(5) man pages for
> >> details.
> >
> > 'scuse me, but shouldn't the errant process be fixed so it can stop
> > and clean up after itself?  Thats the real bug here.
> >
> >
> > Cheers, Gene Heskett
>
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system. And the issue seems to be happening with several different
> types of services. That at least begs the question as to whether the
> problem is really with the services themselves or with the way they
> are controlled by systemd.
>
> I'm guessing that this is just a sort of shakedown cruise problem,
> where it may be that those who develop and maintain some packages will
> have to customize those packages' service units to work properly with
> systemd OR that there are problems with systemd itself OR both.
>
> Or maybe end users like me just need to learn to deal with systemd.
> However, the idea of having end users edit service units hardly seems
> like an ideal routine.
>
> Regards,
> JP

I can agree with that. I can hack up a bash script now & then, but 
wholesale patching really is the sources problem once he/she is aware 
there is a problem.  But it bugs the heck out of me that the guy/gal 
doing the codeing doesn't watch the user lists, so it all has to wait on 
someone qualified enough to wade thru the bug reporter forms and 
actually file the bug.  Thats quite often a week or more additional 
delay before they are aware that there really is a problem.

In the meantime, its hit another 200 users, discouraging them from ever 
touching linux again.  In that regard, we are our own worst enemy at 
times.  Unfortunately, the oar I steer this ship with could be swapped 
for a toothpick and have exactly the same result.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: A stop job is running for...

2015-12-02 Thread Neal P. Murphy

On Thu, 3 Dec 2015 15:48:07 +1300
Chris Bannister  wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > 
> > In the meantime, its hit another 200 users, discouraging them from ever 
> > touching linux again.  In that regard, we are our own worst enemy at 
> > times.  Unfortunately, the oar I steer this ship with could be swapped 
> > for a toothpick and have exactly the same result.
> 
> Or you could be in the Windoze world ' stuck up *cough* *cough* 
> *whistle* *whistle* ... with no paddle.' :)
> 

And half a gnu.

Re: A stop job is running for...

On Wednesday 02 December 2015 21:48:07 Chris Bannister wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.  In that regard, we are our own worst
> > enemy at times.  Unfortunately, the oar I steer this ship with could
> > be swapped for a toothpick and have exactly the same result.
>
> Or you could be in the Windoze world ' stuck up *cough* *cough*
> *whistle* *whistle* ... with no paddle.' :)

Why the heck to do think I'm here Chris?  I don't allow winderz on the 
property unless I get suckered into trying to fix a box full of viri and 
keyloggers they picked up while trolling for good porn or the next get 
rich quick scheme?  I've already been there, done that, skipped the 
T-shirt, and swore I'd never do that again.  I have come to the 
conclusion that winderz lusers deserve what they get.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: A stop job is running for...

On Wednesday 02 December 2015 22:05:10 Neal P. Murphy wrote:

> On Thu, 3 Dec 2015 15:48:07 +1300
>
> Chris Bannister  wrote:
> > On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > > In the meantime, its hit another 200 users, discouraging them from
> > > ever touching linux again.  In that regard, we are our own worst
> > > enemy at times.  Unfortunately, the oar I steer this ship with
> > > could be swapped for a toothpick and have exactly the same result.
> >
> > Or you could be in the Windoze world ' stuck up *cough* *cough*
> > *whistle* *whistle* ... with no paddle.' :)
>
> And half a gnu.

And how is that best done on the barbie?

Sorry, couldn't resist, must do better.  Or do I get the Senior Citizen 
discount on this stuff?  As probably the oldest subscriber to this list 
at 81, does that count?  Or is there someone older yet?  ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page

Re: A stop job is running for...

2015-12-02 Thread Nicolas George

Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
>  But it bugs the heck out of me that the guy/gal 
> doing the codeing doesn't watch the user lists, so it all has to wait on 
> someone qualified enough to wade thru the bug reporter forms and 
> actually file the bug.

Developer time is valuable.

> Thats quite often a week or more additional 
> delay before they are aware that there really is a problem.

Regarding support with guaranteed reaction time, you get exactly your
money's worth: 0.

> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.

If these people are so easily discouraged, and especially definitively
discouraged, they probably belong to the kind of people who only ever
complain and never contribute back. Maybe the community is better without
them.

> Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Libre Software development is a meritocracy, not a democracy. Your oar is
exactly how large you make it. That means Linus' is larger than yours, of
course, and that is only right. I am still writing about steering oar.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: A stop job is running for...

2015-12-02 Thread Chris Bannister

On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> 
> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.  In that regard, we are our own worst enemy at 
> times.  Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Or you could be in the Windoze world ' stuck up *cough* *cough* 
*whistle* *whistle* ... with no paddle.' :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: A stop job is running for...


On 12/02/2015 05:59 PM, Don Armstrong wrote:

On Wed, 02 Dec 2015, Jape Person wrote:

It's occurred to me that, though I have occasionally seen service
shutown issues with sysv-init, they were never as pervasive or
repetitve as it has been since switching to systemd as the init
system.


This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.



Yes, that was my understanding. Sysv-init worked just fine for my my use 
cases, but I can easily see that the arrangement might not work so well 
for something like, say, a print server.



If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.



I finally found this older thread(1) which gave me some ideas as to how 
to proceed in trying to find the cause of the issue.


I want to be useful, but it takes a bit of time for those of us who 
fumble about in darkness to find the walls. We have to find one of those 
before we stand a chance of getting to the cave entrance. I may return 
if I don't first impale myself on a stalagmite.


;-)

JP

(1) https://bugzilla.redhat.com/show_bug.cgi?id=1044602

Re: A stop job is running for...

2015-12-02 Thread Martin Read


On 02/12/15 03:07, James P. Wallen wrote:

Thanks for your response, Sven. It's nice to know that someone else has
seen this type of problem. I was thinking that this could be
self-inflicted. Perhaps that's a little less likely now.

So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking
is, do I need to start poring over systemd documentation to see if there
might be a way to control this behavior?


If a stop job is taking two minutes, that suggests that the service has 
one or more ExecStop lines defined in its service unit and that one of 
those commands is taking an unduly long time to complete for some reason.


The default and per-service timeout values for stopping a service (after 
which systemd gives up and sends fatal signals to all of the service's 
processes) are configurable; see the systemd-system.conf(5) and 
systemd.service(5) man pages for details.

Re: A stop job is running for...

2015-12-01 Thread James P. Wallen




On 12/01/2015 09:47 AM, Sven Arvidsson wrote:

On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote:

Make remote CUPS printers available locally
Network Time Synchronization

For several weeks I've been seeing this stop job notification for
these
two items frequently when rebooting or shutting down two of my four
testing systems.

The first notification counts all the way up to 1 min 30 sec before
the
shutdown scroll restarts. The second notification only counts for a
few
seconds before terminating.

I'm a patient guy, but adding almost two minutes to almost every
restart
or shutdown procedure gets a bit tedious after a while.


Yes, I have noticed this too, but with different services. So it's
probably not specific to CUPS or NTP.

Unfortunately it seems to always happen when I need to shutdown quickly
(thunderstorms). Would be great if it was possible to configure the
countdown to simply kill the service after a few seconds and proceed
with shutdown/reboot.



Thanks for your response, Sven. It's nice to know that someone else has 
seen this type of problem. I was thinking that this could be 
self-inflicted. Perhaps that's a little less likely now.


So, is this behavior controlled by systemd?

I'm not trying to start a fracas. I'm really interested. What I'm asking 
is, do I need to start poring over systemd documentation to see if there 
might be a way to control this behavior?

Re: A stop job is running for...

2015-12-01 Thread Sven Arvidsson

On Mon, 2015-11-30 at 21:04 -0500, Jape Person wrote:
> Make remote CUPS printers available locally
> Network Time Synchronization
> 
> For several weeks I've been seeing this stop job notification for
> these 
> two items frequently when rebooting or shutting down two of my four 
> testing systems.
> 
> The first notification counts all the way up to 1 min 30 sec before
> the 
> shutdown scroll restarts. The second notification only counts for a
> few 
> seconds before terminating.
> 
> I'm a patient guy, but adding almost two minutes to almost every
> restart 
> or shutdown procedure gets a bit tedious after a while.

Yes, I have noticed this too, but with different services. So it's
probably not specific to CUPS or NTP.

Unfortunately it seems to always happen when I need to shutdown quickly
(thunderstorms). Would be great if it was possible to configure the
countdown to simply kill the service after a few seconds and proceed
with shutdown/reboot.

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5

signature.asc
Description: This is a digitally signed message part

A stop job is running for...

2015-11-30 Thread Jape Person


Make remote CUPS printers available locally
Network Time Synchronization

For several weeks I've been seeing this stop job notification for these 
two items frequently when rebooting or shutting down two of my four 
testing systems.


The first notification counts all the way up to 1 min 30 sec before the 
shutdown scroll restarts. The second notification only counts for a few 
seconds before terminating.


I'm a patient guy, but adding almost two minutes to almost every restart 
or shutdown procedure gets a bit tedious after a while.


This is a small home network with 4 systems running Debian Stretch and 
two printers. One printer is attached via USB to one of the Stretch 
systems showing the error. It is shared on the network. The other 
printer is a network MFP attached via CAT5e to the router.


The two Stretch systems which show this behavior are both used directly 
through the desktop environment. The other two PCs are only accessed 
ordinarily via SSH, and I have not seen them display the notification. 
(They sit near my workstation, and I can watch their screens when 
rebooting or shutting them down.)


The systems use Xfce DE and LightDM. The USB printer was set up using 
CUPS. The network MFP was installed using the hp-setup utility from 
hplip. Both printers are installed on all four systems.


The only possibly related hit when searching -- interestingly enough -- 
concerned cups-bsd in the MacOS and the HP LaserJet 1300 printer from a 
few years ago. An HP LaserJet 1300 happens to be the USB-attached 
printer on this network. The only advice offered to fix the problem was 
to restart the computer and the printer. I didn't think that would fix 
the issue, and it didn't.


I found nothing pertinent in the Debian bug tracker on the cups-bsd package.

Suggestions, anyone?

I'm grateful for your time and any ideas you might provide.

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-17 Thread Tom H

On Fri, Aug 15, 2014 at 7:46 AM, Chris Bannister
cbannis...@slingshot.co.nz wrote:
 On Thu, Aug 14, 2014 at 10:35:11AM -0400, Tom H wrote:

 Stop in stop job isn't an adjective, it's a noun (or an
 attributive noun) just like office in office chair.

 Or it could be a verb, as in a command Stop job! :)
 Maybe Steve heard it years ago. :)

:)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=Sx=p2Ecu11tYROoNiSLK6jfqgkV1brvESYaucDP1J=+8...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-16 Thread Paul E Condon

On 20140814_1035-0400, Tom H wrote:
 On Thu, Aug 14, 2014 at 1:04 AM, Paul E Condon
 pecon...@mesanetworks.net wrote:
 
  In English, both 'stop job' and 'stopped job' are an adjective
  modifying a noun. The noun in both cases is 'job'. 'stop job' is a
  noun phrase expressing a type of job, and must be some kind of geeky
  usage. OTOH, the noun phrase 'stopped job' is a job that is not
  progressing, or not running. But in this context, 'job' must itself
  have a geeky, technical jargon meaning.
 
 I don't understand why you've got a bee under your bonnet because of
 the stop job phrase!
 
 Stop in stop job isn't an adjective, it's a noun (or an
 attributive noun) just like office in office chair.
 

I wasn't aware of the existence of the term 'attributive noun' until
you used it. It wasn't taught in my H.S. English class in 1949. At
least, I don't remember it being taught.  Google gives several
descriptions of what it means that boil down to 'a noun that can be
used as an adjective,' or 'a noun that is being used as an adjective.'
I haven't yet understood why the distinction between 'attributive noun'
and 'adjective' is important. Is it yet another independent part of
speech? Distinct from both 'noun' and 'adjective'? But honestly, I
don't think I would understand an explanation. English is a very
irregular language, and rules of grammar are an attempt at regularity,
which contradicts the spirit of the language.

Best regards,
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816224746.ga3...@big.lan.gnu

RE: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Bonno Bloksma

Hi,

  I interpret the quoted string in the Subject: header as being flawed 
  use of English language. 'stop' should be 'stopped'. And, there is a
 
 That would definitely be clearer.
 
 I was interpreting it as some special systemd shutdown-ey thing which 
 runs around trying to stop things, and that there might be various of 
 these, and one of them has a problem.

 Yes, I believe this is the correct interpretation. SystemD will tell all 
 services
  to stop.  It will  then wait  until all  those sevices  have stopped. Some 
 services will  stop immediately, but  some need  a little longer to  flush 
 logs,
 finish servicing  a request or whatever.  After a period of seconds, it 
 appears 
 that SystemD  will pop up a message to the effect  of I'm  still  here,  
 still 
 responding.  I'm  just waiting  for service X to tell me it has stopped. 
 Given 
 what was said earlier in the thread, I  suspect this will  continue for  90 
 seconds until  it finally gives up waiting.

I wonder if the people developing this are paying attention to a development in 
de Windows environment where the latest thing is that de service can report 
back that it is indeed still trying to stop and not just hung and not reporting 
back. Windows will now kill a service after a certain time when shutting down, 
in some cases it was killing a database that took A LONG TIME to shut down and 
cause the database to become inconsistent.
If systemd is trying to become smart about stopping services it might be a good 
idea to have this built in. Also not just have the service report back I am 
still busy but also with a progress indicator which NEEDS to increase at each 
report so system can detect whether the service is indeed progressing towards a 
stopped state or hung in the getting there.

Bonno Bloksma

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Chris Bannister

On Thu, Aug 14, 2014 at 10:35:11AM -0400, Tom H wrote:
 On Thu, Aug 14, 2014 at 1:04 AM, Paul E Condon
 pecon...@mesanetworks.net wrote:
 
  In English, both 'stop job' and 'stopped job' are an adjective
  modifying a noun. The noun in both cases is 'job'. 'stop job' is a
  noun phrase expressing a type of job, and must be some kind of geeky
  usage. OTOH, the noun phrase 'stopped job' is a job that is not
  progressing, or not running. But in this context, 'job' must itself
  have a geeky, technical jargon meaning.
 
 I don't understand why you've got a bee under your bonnet because of
 the stop job phrase!
 
 Stop in stop job isn't an adjective, it's a noun (or an
 attributive noun) just like office in office chair.

Or it could be a verb, as in a command Stop job! :)
Maybe Steve heard it years ago. :)

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815114658.GH11178@tal

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Henrique de Moraes Holschuh

On Fri, 15 Aug 2014, Bonno Bloksma wrote:
 I wonder if the people developing this are paying attention to a
 development in de Windows environment where the latest thing is that de
 service can report back that it is indeed still trying to stop and not
 just hung and not reporting back. Windows will now kill a service after a

Debian initscripts has been killing (after a timeout) any stuck services on
reboot/shutdown for at least a decade.

systemd does the same, only it has a longer default timeout than Debian
initscripts's default timeout.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815120758.ga26...@khazad-dum.debian.net

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Zenaan Harkness

On 8/15/14, Henrique de Moraes Holschuh h...@debian.org wrote:
 On Fri, 15 Aug 2014, Bonno Bloksma wrote:
 I wonder if the people developing this are paying attention to a
 development in de Windows environment where the latest thing is that de
 service can report back that it is indeed still trying to stop and not
 just hung and not reporting back. Windows will now kill a service after a

 Debian initscripts has been killing (after a timeout) any stuck services on
 reboot/shutdown for at least a decade.

 systemd does the same, only it has a longer default timeout than Debian
 initscripts's default timeout.

Time to go more verbose ... at this point in systemde, I need more
verbosity again (I already enabled std log/output as per earlier
threads).

And possibly speed up kill timeout, but I'd rather know what's balking.

Ideally, as is, and if 20s is reached, dump verbose/debug output, to
help me identify iff problem.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOsGNSSvrzX5EzHQuJvA28=rw2o5sQA9RWJ9Hz+a=y6b1yn...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Steve Litt

On Fri, 15 Aug 2014 09:19:48 +
Bonno Bloksma b.blok...@tio.nl wrote:

 I wonder if the people developing this are paying attention to a
 development in de Windows environment where the latest thing is that
 de service can report back that it is indeed still trying to stop and
 not just hung and not reporting back. Windows will now kill a service
 after a certain time when shutting down, in some cases it was killing
 a database that took A LONG TIME to shut down and cause the database
 to become inconsistent. If systemd is trying to become smart about
 stopping services it might be a good idea to have this built in. Also
 not just have the service report back I am still busy but also with
 a progress indicator which NEEDS to increase at each report so system
 can detect whether the service is indeed progressing towards a
 stopped state or hung in the getting there.
 
 Bonno Bloksma

Yes. And why stop there? Any process that's been using a lot of
processor for a long time can be nice'd up so it takes smaller slices.
Each process that runs will be configured to the maximum time it can
take lots of processor time.

Systemd can monitor the video, so that not only typing or mousing
resets the timeout, but any change in the screen resets the timeout.

Some processes don't work well together, and systemd can maintain a
database of such processes, perhaps in Postgres, to prevent one of
those processes from running if the other is already running, unless
the processes themselves tell systemd they're aware of the danger and
it's OK.

Systemd's database should include uuid's for specific programs known to
be safe, and should not start others, unless A) The program emits a
uuid to systemd upon being asked to run, and B) that uuid has been put
in the database either by the distribution or by the system
administrator. Before running, systemd will check the md5sum of the
executable to make sure it matches the uuid. Because this might be a
hardship during development, the systemd database will have a column
called lax, which, if true, allows the program to run as long as the
program submits the proper password.

I'm conceptually not a fan of systemd, but you have to admit it opens
up many opportunities.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815093814.07cde...@mydesq2.domain.cxm

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Chris Bannister

On Fri, Aug 15, 2014 at 09:38:14AM -0400, Steve Litt wrote:
 Some processes don't work well together, and systemd can maintain a
 database of such processes, perhaps in Postgres, to prevent one of
 those processes from running if the other is already running, unless
 the processes themselves tell systemd they're aware of the danger and
 it's OK.
 
 Systemd's database should include uuid's for specific programs known to
 be safe, and should not start others, unless A) The program emits a
 uuid to systemd upon being asked to run, and B) that uuid has been put
 in the database either by the distribution or by the system
 administrator. Before running, systemd will check the md5sum of the
 executable to make sure it matches the uuid. Because this might be a
 hardship during development, the systemd database will have a column
 called lax, which, if true, allows the program to run as long as the
 program submits the proper password.
 
 I'm conceptually not a fan of systemd, but you have to admit it opens
 up many opportunities.

You mean systemd should shoulder some of the kernel's work? LOL
Please please, Mr Poettering, I mean it as a joke, honest!

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815141248.GA19964@tal

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Erwan David

Le 12/08/2014 17:48, Michael Biebl a écrit :
 Am 12.08.2014 17:16, schrieb Hugo Vanwoerkom:

 Right.  Debian Sid. 'halt' does not poweroff with systemd.
 Well, yeah. halt is not supposed to power off your system.

 But that is most likely not the issue Zenaan is having


SAme thing wirh stop computer in KDE.

Should we file a bug with gravty corresponding to breaks unrelated
package ?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee3a99.7000...@rail.eu.org

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Henrique de Moraes Holschuh

On Fri, 15 Aug 2014, Erwan David wrote:
  Right.  Debian Sid. 'halt' does not poweroff with systemd.

The halt/reboot/poweroff binary shipped from sysvinit source will request a
direct power-off, halt or reboot to the kernel.  Just give it the -f
option.  And don't complain if this causes data loss.

The manpage of systemd's halt/reboot/poweroff command seems to imply it
supports the -f option.  Again, don't complain if the use of the -f
option causes data loss.

That said, it is not that uncommon for the kernel to not find a way to
safely power down a X86 box.  I won't go into the gory details of why, but
regressions in kernel power-off support are not unheard of.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815174114.gd2...@khazad-dum.debian.net

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Henrique de Moraes Holschuh

On Fri, 15 Aug 2014, Jonathan de Boyne Pollard wrote:
 Bonno Bloksma:
  I wonder if the people developing this are paying attention to a
  development in de Windows environment where the latest thing is that de
  service can report back that it is indeed still trying to stop and not
  just hung and not reporting back.
 
 Henrique de Moraes Holschuh:
  Debian initscripts has been killing (after a timeout) any stuck services on
  reboot/shutdown for at least a decade.
 
 M. Bloksma was, however, talking about the scenario where the SCM does
 not kill the service and the service is not stuck.

Indeed, my fault: I misread.  Sorry about that, Mr. Bloksma.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815180413.gf2...@khazad-dum.debian.net

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-15 Thread Reco

 Hi.

On Sat, 16 Aug 2014 02:12:48 +1200
Chris Bannister cbannis...@slingshot.co.nz wrote:

 You mean systemd should shoulder some of the kernel's work?

A database of conflicting processes is a half-measure. Moreover, an
existing implementation of RDBMS older than systemd such as Postgres is
surely a no-go :)

You see, current Linux kernel's codebase is old, it can be traced back
to 1991. Moreover, current kernel pays little attention to Modern
FreeDesktop Standards™ (for example, kdbus). And, current kernel's
upstream cannot be considered that friendly to systemd.

To work the way it was intended - systemd upstream needs to implement
their own kernel (aka kerneld) and deprecate current one. This approach
grants virtually limitless possibilities.

For example, the problem of conflicting processes can be eliminated by
blacklisting said processes in the kerneld, whereas blacklist would be
transferred by kdbus to the current kerneld instance directly from the
https://cloud.redhat.com :)

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815232740.e6a4d4464ebb985255a87...@gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Zenaan Harkness

On 8/14/14, Paul E Condon pecon...@mesanetworks.net wrote:
 I should stop. I really have very little firm knowledge of systemd,
 just opinions that make sense to me. (tm)

That's TM for YOU son! It's formal english thank you very much. and
(tm) is a very sloppy rendition!! I don't know that we can tolerate
this level of slack any more...

Chris Bannista, I formally disignate you bro (that's the correct
speling, since he Nuu Zoolander) as the Grammatistica Commissioner.
And ChrisB, I now formally report Paul's sloppy, sloppy instance of
(non-!)capitalization for your formal punishment.

Thanks and have a -great- day (TM -- note the capitals),
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnssl47klfj1s1f__avzejprmwyahdokx5escu71ayjh...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Darac Marjal

On Thu, Aug 14, 2014 at 10:03:31PM +1000, Zenaan Harkness wrote:
 On 8/14/14, Paul E Condon pecon...@mesanetworks.net wrote:
  I should stop. I really have very little firm knowledge of systemd,
  just opinions that make sense to me. (tm)
 
 That's TM for YOU son! It's formal english thank you very much. and
 (tm) is a very sloppy rendition!! I don't know that we can tolerate
 this level of slack any more...
 
 Chris Bannista, I formally disignate you bro (that's the correct
 speling, since he Nuu Zoolander) as the Grammatistica Commissioner.
 And ChrisB, I now formally report Paul's sloppy, sloppy instance of
 (non-!)capitalization for your formal punishment.
 
 Thanks and have a -great- day (TM -- note the capitals),

To  clarify further,  TM  is as  “sloppy” a  shortcut  as (tm).  The
correct rendering should be ™; that is: U+2122, “TRADE MARK SIGN”.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814124108.ga11...@darac.org.uk

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Zenaan Harkness

On 8/14/14, Darac Marjal mailingl...@darac.org.uk wrote:
 On Thu, Aug 14, 2014 at 10:03:31PM +1000, Zenaan Harkness wrote:
 On 8/14/14, Paul E Condon pecon...@mesanetworks.net wrote:
  I should stop. I really have very little firm knowledge of systemd,
  just opinions that make sense to me. (tm)

 That's TM for YOU son! It's formal english thank you very much. and
 (tm) is a very sloppy rendition!! I don't know that we can tolerate
 this level of slack any more...

 Chris Bannista, I formally disignate you bro (that's the correct
 speling, since he Nuu Zoolander) as the Grammatistica Commissioner.
 And ChrisB, I now formally report Paul's sloppy, sloppy instance of
 (non-!)capitalization for your formal punishment.

 Thanks and have a -great- day (TM -- note the capitals),

 To  clarify further,  TM  is as  “sloppy” a  shortcut  as (tm).  The
 correct rendering should be ™; that is: U+2122, “TRADE MARK SIGN”.

ChrisBanalGrammatistica, I hereby formally duly readily
specifically unequivocally report myself for sloppiness,
or signing and speling and grammar!
Intransigence shall -not- be tolerated,
Zenaan


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnssfg+wpoh-yntryiox7toaurca6wudj4rpczwtcyko...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread saint

Zenaan Harkness writes:

  ChrisBanalGrammatistica,

Grammatistica? Which language does this word belong to? Ancient
Debianese, possibly pre-Vax era?

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian

Warning: gnome-config-daemon considered more dangerous than GOTO


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21484.50225.571935.947...@mail.eng.it

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Tom H

On Thu, Aug 14, 2014 at 1:04 AM, Paul E Condon
pecon...@mesanetworks.net wrote:

 In English, both 'stop job' and 'stopped job' are an adjective
 modifying a noun. The noun in both cases is 'job'. 'stop job' is a
 noun phrase expressing a type of job, and must be some kind of geeky
 usage. OTOH, the noun phrase 'stopped job' is a job that is not
 progressing, or not running. But in this context, 'job' must itself
 have a geeky, technical jargon meaning.

I don't understand why you've got a bee under your bonnet because of
the stop job phrase!

Stop in stop job isn't an adjective, it's a noun (or an
attributive noun) just like office in office chair.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=SxjM8=tX7qBip5qtVvWnVu5vdfWvTZ9zfTqXkUs=ym...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Iain M Conochie


On 12/08/14 22:23, Lisi Reisz wrote:

On Tuesday 12 August 2014 17:53:19 Martin Steigerwald wrote:

But if the english meaning of the words give
exact this difference, so well. In my understanding there never was much of
a difference between halt and poweroff.

I'm not quite clear what you are saying, but if you are saying that there is
not give much difference in the English meaning of the words poweroff and
halt, then I must take issue with you.

Halt simply means stop.  Poweroff means turn the power off.  A big difference
in the words.  Think of a car at traffic lights.  You stop it: halt it.  You
do not power off, i.e. turn the engine off.  (Unless you accidentally stall
it!)
Yet this is exactly what my 2 year old car does now. I halt at the 
lights and the engine powers off. Is this a bug?


Given enough usage, a bug can become a feature.

Iain


Lisi

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread The Wanderer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/14/2014 10:35 AM, Tom H wrote:

 On Thu, Aug 14, 2014 at 1:04 AM, Paul E Condon 
 pecon...@mesanetworks.net wrote:
 
 In English, both 'stop job' and 'stopped job' are an adjective
 modifying a noun. The noun in both cases is 'job'. 'stop job' is a
 noun phrase expressing a type of job, and must be some kind of
 geeky usage. OTOH, the noun phrase 'stopped job' is a job that is
 not progressing, or not running. But in this context, 'job' must
 itself have a geeky, technical jargon meaning.
 
 I don't understand why you've got a bee under your bonnet because of
 the stop job phrase!
 
 Stop in stop job isn't an adjective, it's a noun (or an
 attributive noun) just like office in office chair.

Technically speaking, in office chair, the word office is an adjective.

Most words in English can serve as multiple different parts of speech,
depending on context. Nouns can be verbed, verbs can be nouned, and - as
we see here - nouns can be adjectivized, trivially.


That said, yes, a stop job is a job intended to stop something. (Think
of the phrase a stop-job order, that is, an order to stop a job that
otherwise would go forward.)

The phrase is still non-obvious at a glance to the uninitiated - I had
trouble figuring out that it wasn't a transcription error for stopped
job, and then figuring out what it did mean, myself - but it is a
reasonable one to choose from the perspective of someone who does know
what's being talked about.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJT7NuqAAoJEASpNY00KDJr9PYP/0j116FU93DILPVuF8i7rJDr
tHptGTGBFJt7rtpw//igCRYeNrZTgAZ0XiZXGZKDJAWKjJQ0/40/OPeB6yS1ptbW
7xfo9w4vtmqf05qi2JXxuin54cL91iYVhuBCbc7lSIaC3q4+wvJZoJThKRBs1e0x
ioRCecz+641ZFkcSv5WeGP5uYHVC/AI2t7FBAHyIdpyTEYn43bHfDhqNP0iMCCi8
15InRQolVuoMzzyCb8JHnMuZBpWgk3LEBjP4qB2rNuy57ZgHAuun8GaKXfCJ1weW
KCXtA+FxXQ24yXw13ZD9HB3pSTbI/y+o7Cqr5hLENYlvH5EW+jTJC6PJrC2IN3DK
a1kvWLi8I/WEnexy14w2RaJQaU9rk1fwbijHGJ/sgRx83Jcs2iUaJY4+b2JpcAPC
WxtXQ0Q7Yu1siMAS/U7xzWYUXRODFRGECSAXJywh7ZV0znabKhukgJq9FmmJLvq2
jFEwH1nu/qkHgAI6pXqNNjSm7Z8rTMkj8nRVBjSR7V5ftbisazjwV27Eja6tPE/I
cml7sJl5RV84hs1M1GzVsYoTFL8Lqt4NpqFBzdCdvZTavz9oDnWU20HpmJNJNpMI
bdxSfFFRR8fiE10gWEP0ta6NoIJBX4ZglCLg6IlPYr6RW+sf7xqZjrasEpAx/xjh
IJ/5vUmEYDWrW/FKim6J
=WQVw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ecdbab.3030...@fastmail.fm

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Curt

On 2014-08-14, Iain M Conochie i...@thargoid.co.uk wrote:

 Yet this is exactly what my 2 year old car does now. I halt at the 
 lights and the engine powers off. Is this a bug?

Depends.

 Given enough usage, a bug can become a feature.

Some clever folks turn bugs into features, I reckon:

http://www.usatoday.com/story/money/business/2014/07/23/stop-start-engines-fuel-savings-aaa/13053447/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnlupnu3.2c0.cu...@einstein.electron.org

Grammatisticality: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Steve Litt

On Thu, 14 Aug 2014 16:14:09 +0200
sa...@eng.it wrote:

 Zenaan Harkness writes:
 
   ChrisBanalGrammatistica,
 
 Grammatistica? Which language does this word belong to? Ancient
 Debianese, possibly pre-Vax era?
 

At this point, mightn't it be good to change the subject, just in case
the original poster still wants to hear some more technical
information about poweroff?


SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814133258.72487...@mydesq2.domain.cxm

Re: Grammatisticality: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-14 Thread Zenaan Harkness

On 8/15/14, Steve Litt sl...@troubleshooters.com wrote:
 On Thu, 14 Aug 2014 16:14:09 +0200
 sa...@eng.it wrote:
 Zenaan Harkness writes:

   ChrisBanalGrammatistica,

 Grammatistica? Which language does this word belong to? Ancient
 Debianese, possibly pre-Vax era?

 At this point, mightn't it be good to change the subject, just in case
 the original poster still wants to hear some more technical
 information about poweroff?

That would be me :)

I guess I do need to be charged with comedijacking my own thread.
Sorry about that.flogs self mercilessly with hessian flogging device;
crys out piteously; continues nonetheless

And by the way, I haven't yet reproduced the problem (although it was
happening regularly), so my next test is to suspend then unsuspend,
then try to poweroff from XFCE's gui. I shall report back on the
status of that.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOsGNSSCAD=c52cgig-8ve4a27fekmwzbbj2uwy5ro1otpa...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-13 Thread Tom H

On Tue, Aug 12, 2014 at 2:51 PM, Paul E Condon
pecon...@mesanetworks.net 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
 bug in the script that fails to evaluate the variable USER and
 therefore fails to print the name of the user (aka. owner) of the
 stopped job in Session 2.

The wording's probably derived from the fact that it's a systemctl
stop ... job that's failing.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=SyvexA3X56=ZsPTjeiXmhZ6HfEiYvPeG3evR+ir=eo...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-13 Thread Darac Marjal

On Wed, Aug 13, 2014 at 11:15:22AM +1000, Zenaan Harkness wrote:
 On 8/13/14, Paul E Condon pecon...@mesanetworks.net 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
 
 That would definitely be clearer.
 
 I was interpreting it as some special systemd shutdown-ey thing which
 runs around trying to stop things, and that there might be various of
 these, and one of them has a problem.

Yes, I believe this is the correct interpretation. SystemD will tell all
services  to stop.  It will  then wait  until all  those sevices  have
stopped. Some  services will  stop immediately, but  some need  a little
longer to  flush logs, finish servicing  a request or whatever.  After a
period of seconds, it appears that SystemD  will pop up a message to the
effect  of I'm  still  here,  still responding.  I'm  just waiting  for
service X to tell me it has stopped. Given what was said earlier in the
thread, I  suspect this will  continue for  90 seconds until  it finally
gives up waiting.

 
 I.e. stop job being a noun.

Stop Command,  perhaps? Stop-Service  command would be  even clearer
(though  that  literal  command   doesn't  exist).  Perhaps  a  complete
rewording to Still waiting for Service  $FOO in Session 2 of User $USER
to stop would be clearest.



signature.asc
Description: Digital signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-13 Thread Paul E Condon

On 20140813_1033+0100, Darac Marjal wrote:
 On Wed, Aug 13, 2014 at 11:15:22AM +1000, Zenaan Harkness wrote:
  On 8/13/14, Paul E Condon pecon...@mesanetworks.net 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
  
  That would definitely be clearer.
  
  I was interpreting it as some special systemd shutdown-ey thing which
  runs around trying to stop things, and that there might be various of
  these, and one of them has a problem.
 
 Yes, I believe this is the correct interpretation. SystemD will tell all
 services  to stop.  It will  then wait  until all  those sevices  have
 stopped. Some  services will  stop immediately, but  some need  a little
 longer to  flush logs, finish servicing  a request or whatever.  After a
 period of seconds, it appears that SystemD  will pop up a message to the
 effect  of I'm  still  here,  still responding.  I'm  just waiting  for
 service X to tell me it has stopped. Given what was said earlier in the
 thread, I  suspect this will  continue for  90 seconds until  it finally
 gives up waiting.
 
  
  I.e. stop job being a noun.
 

In English, both 'stop job' and 'stopped job' are an adjective
modifying a noun. The noun in both cases is 'job'. 'stop job' is a
noun phrase expressing a type of job, and must be some kind of geeky
usage. OTOH, the noun phrase 'stopped job' is a job that is not
progressing, or not running. But in this context, 'job' must itself
have a geeky, technical jargon meaning. I notice that you render
'systemd' as SystemD, the thought police of systemd object to the
capital D. Be warned. It marks you as not one of the cognoscenti.

There is a lot going on here in the use of language. Systemd people
seem to have developed there own systemd jargon which sounds like UNIX
jargon to the un-initiated. They may believe it is UNIX jargon,
but when closely questioned I think they will reveal a belief system
about UNIX that differs from the mainstream of geeky person's. To them,
it is just UNIX, only better. 

 Stop Command,  perhaps? Stop-Service  command would be  even clearer
 (though  that  literal  command   doesn't  exist).  Perhaps  a  complete
 rewording to Still waiting for Service  $FOO in Session 2 of User $USER
 to stop would be clearest.

Seems good to me, but we don't have a clear idea of what 'Session 2'
is. It might actually be a concept, which, if properly understood
would be better expressed with a totally different ordering of
the words. 

My brother Joe spent his working life at Bell Labs in the same
building as the inventors of UNIX told me decades ago about the go
arounds in the lunch room on topics of word choice in documantation. 
All of them had taken old fashioned high school English on there way 
to earning their engineering or science degree. They cared about 
being understood. He died 2yrs ago. It would have been nice to have
ask him about this situation. I think he actually helped the UNIX 
guys by being a audience on whom to test their language.

I think that all commenters would agree that the message is somewhat
confusing. Something is holding up the process of shutting down some
process. There needs to be a standard glossary of terms to use to
express every particular that the message is attempting to communicate
to the user. And, there needs to be some suggestion of what the user
should do about the situation, or where in the operator's manual to
read further information. It really ought to be easier to understand
than the true meaning of the Book of Genesis.

I should stop. I really have very little firm knowledge of systemd,
just opinions that make sense to me. (tm)

Best regards,
-- 
Paul E Condon 
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814050409.ga13...@big.lan.gnu

systemd fails to poweroff - A stop job is running for Session 2 of user $USER

Debian sid

systemd currently fails to poweroff for me

XFCE (appears to) exit, the mouse point shows
for a while, then the kernel/ shutdown log appears.

The last message is:
A stop job is running for Session 2 of user me

Red asterisks (up to 3) appear to oscillate at left
edge in an ascii wait for me animation.

Requires hard powercycle to poweroff.

How might I debug this?

TIA
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caosgnssbq+n88khxbc7mj4q_hflqn1hdbftubjgrxq5hg1_...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Michael Biebl

Am 12.08.2014 16:50, schrieb Zenaan Harkness:
 Debian sid
 
 systemd currently fails to poweroff for me
 
 XFCE (appears to) exit, the mouse point shows
 for a while, then the kernel/ shutdown log appears.
 
 The last message is:
 A stop job is running for Session 2 of user me
 
 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.
 

Have you waited at least 90 secs, which is the default timeout?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Hugo Vanwoerkom


Zenaan Harkness wrote:

Debian sid

systemd currently fails to poweroff for me

XFCE (appears to) exit, the mouse point shows
for a while, then the kernel/ shutdown log appears.

The last message is:
A stop job is running for Session 2 of user me

Red asterisks (up to 3) appear to oscillate at left
edge in an ascii wait for me animation.

Requires hard powercycle to poweroff.

How might I debug this?



Right.  Debian Sid. 'halt' does not poweroff with systemd.

Hugo


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/lsdb4a$6jv$1...@ger.gmane.org

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Bzzzz

On Wed, 13 Aug 2014 00:50:31 +1000
Zenaan Harkness z...@freedbms.net wrote:

 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.

You're a lucky guy: I don't have even one asterisk (only
a white underscore and a blinking cursor - on a laptop).

But I'm not that sure it is tied to systemd because
on my spare system (also sid, but the bare minimum
to troubleshoot main system, just in case…), the shutdown
works like a charm.

-- 
guend people criticize windoz…
guend but since I have my new computer, I have had no problems with it
kayoch but didn't you just buy a Mac?
guend yes, so what?


signature.asc
Description: PGP signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Michael Biebl

Am 12.08.2014 17:16, schrieb Hugo Vanwoerkom:

 Right.  Debian Sid. 'halt' does not poweroff with systemd.

Well, yeah. halt is not supposed to power off your system.

But that is most likely not the issue Zenaan is having

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Darac Marjal

On Tue, Aug 12, 2014 at 10:16:27AM -0500, Hugo Vanwoerkom wrote:
 Zenaan Harkness wrote:
 Debian sid
 
 systemd currently fails to poweroff for me
 
 XFCE (appears to) exit, the mouse point shows
 for a while, then the kernel/ shutdown log appears.
 
 The last message is:
 A stop job is running for Session 2 of user me
 
 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.
 
 Requires hard powercycle to poweroff.
 
 How might I debug this?
 
 
 Right.  Debian Sid. 'halt' does not poweroff with systemd.

That's a totally  different issue, though. With systemd  both 'halt' and
'poweroff' should run through the init sequence (stop all services, send
TERM to all processes, send KILL to all processes). 'halt' then stops at
this point - the  only thing left running is then  the kernel (there's a
certain pattern of work that involves  running a machine like this for a
firewall. All the rules are loaded  into the kernel and then the machine
is halted. The  kernel can still process packets happily,  but there are
no user space processes which can alter/interfere).

What Zenaan is talking about is systemd  asking a service to stop and it
taking too long to do so (perhaps it never will, perhaps it just needs a
long time)


 Hugo


 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject
 of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/lsdb4a$6jv$1...@ger.gmane.org
 


signature.asc
Description: Digital signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Javier Barroso

On Tue, Aug 12, 2014 at 5:16 PM, Hugo Vanwoerkom hvw59...@care2.com wrote:
 Zenaan Harkness wrote:

 Debian sid

 systemd currently fails to poweroff for me

 XFCE (appears to) exit, the mouse point shows
 for a while, then the kernel/ shutdown log appears.

 The last message is:
 A stop job is running for Session 2 of user me

 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.

 Requires hard powercycle to poweroff.

 How might I debug this?


 Right.  Debian Sid. 'halt' does not poweroff with systemd.
I think this behaviour has changed from pre-systemd era.

At halt/poweroff/reboot manpage :
DESCRIPTION
   halt, poweroff, reboot may be used to halt, power-off or reboot the
   machine.

I think it should be better explain what is exactly halt and which is
the difference with poweroff

As I understand, power off is like you press the power button some seconds.
Halt (as current behaviour) is stop all process but pid 1

There is the -p switch to halt, or the --halt switch to poweroff,
so halt can power off the machine or power off can stop all process in
an ordered way

Regards,


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAL5yMZS_D68vLw9KZaZgbRbMXA0C_r0iHcdSh6e=at-hxrv...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Martin Steigerwald

Am Dienstag, 12. August 2014, 17:48:10 schrieb Michael Biebl:
 Am 12.08.2014 17:16, schrieb Hugo Vanwoerkom:
  Right.  Debian Sid. 'halt' does not poweroff with systemd.
 
 Well, yeah. halt is not supposed to power off your system.

Interestingly in the last ten years I have used halt exactly to power off a 
machine, when not using a desktop mechanism.

On all systems with working ACPI I tried this on it did so. On those where 
ACPI is broken, it sometimes did not power off the machine.

merkaba:~ ls -l /sbin/halt
-rwxr-xr-x 1 root root 18776 Aug  3 21:01 /sbin/halt
merkaba:~ ls -l /sbin/poweroff 
lrwxrwxrwx 1 root root 4 Aug  3 21:01 /sbin/poweroff - halt

So it differentiates behavior on command name?

The manpage for halt is more than unclear on the exact semantics.

I´d prefer clear commands with clear definitions of their behavior instead of 
guess work – will it call shutdown? or not.

I like System Commands in systemctl manpage regarding this. Yet also this is 
just saying halt or power off. But if the english meaning of the words give 
exact this difference, so well. In my understanding there never was much of a 
difference between halt and poweroff.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

signature.asc
Description: This is a digitally signed message part.

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Tom H

On Tue, Aug 12, 2014 at 10:50 AM, Zenaan Harkness z...@freedbms.net wrote:

 Debian sid

 systemd currently fails to poweroff for me

 XFCE (appears to) exit, the mouse point shows
 for a while, then the kernel/ shutdown log appears.

 The last message is:
 A stop job is running for Session 2 of user me

 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.

 Requires hard powercycle to poweroff.

 How might I debug this?

https://lists.debian.org/debian-user/2014/07/msg01108.html

I've been assuming that the Debian maintainers had backported the fix
to (1) in the link above, but perhaps not. I haven't experienced this
though and you seem to be the first to report this on the list in
spite of many seemingly using systemd in testing and unstable,
willingly or not.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOdo=SwZ5HrXj8JdgJGbJPcjjHk5nKRjp6rAmdi4gZzL3=i...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Paul E Condon

I interpret the quoted string in the Subject: header as being flawed
use of English language. 'stop' should be 'stopped'. And, there is a
bug in the script that fails to evaluate the variable USER and
therefore fails to print the name of the user (aka. owner) of the
stopped job in Session 2.

Did OP attempted to connect to Session 2 and terminate the job there?

Does the message really keep the system from executing poweroff? Or,
does it just introduce a delay long enough for the user who is
requesting the poweroff to reconsider and abort his request?

What did the OP actually do that he hoped would cause a poweroff?
i.e. what did he type? or button did he click?

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.

I'm assuming that it is OK to assume that the user who did whatever made
his computer spit out this message understands what a stopped job is, but
I'm unaware of any Debian manual of style for error messages as newspapers
have manuals of style for news item they print. Is there one? If so, it
should give advice on the use of 'for' and 'of' in this context.

OTOH, maybe I misunderstand the situation.

HTH

On 20140812_1804+0200, Javier Barroso wrote:
On Tue, Aug 12, 2014 at 5:16 PM, Hugo Vanwoerkom hvw59...@care2.com wrote:
Zenaan Harkness wrote:

Debian sid

systemd currently fails to poweroff for me

XFCE (appears to) exit, the mouse point shows
for a while, then the kernel/ shutdown log appears.

The last message is:
A stop job is running for Session 2 of user me

Red asterisks (up to 3) appear to oscillate at left
edge in an ascii wait for me animation.

Requires hard powercycle to poweroff.

How might I debug this?

Right. Debian Sid. 'halt' does not poweroff with systemd.
I think this behaviour has changed from pre-systemd era.

At halt/poweroff/reboot manpage :
DESCRIPTION
halt, poweroff, reboot may be used to halt, power-off or reboot the
machine.

I think it should be better explain what is exactly halt and which is
the difference with poweroff

As I understand, power off is like you press the power button some seconds.
Halt (as current behaviour) is stop all process but pid 1

There is the -p switch to halt, or the --halt switch to poweroff,
so halt can power off the machine or power off can stop all process in
an ordered way

Regards,

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAL5yMZS_D68vLw9KZaZgbRbMXA0C_r0iHcdSh6e=at-hxrv...@mail.gmail.com

--
Paul E Condon
pecon...@mesanetworks.net

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140812185112.ga24...@big.lan.gnu

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

2014-08-12 Thread Andrei POPESCU

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.

Kind regards,
Andrei
P.S. CC and Reply-to: -offtopic as this is not very relevant to Debian
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

2014-08-12 Thread Lisi Reisz

On Tuesday 12 August 2014 17:53:19 Martin Steigerwald wrote:
 But if the english meaning of the words give
 exact this difference, so well. In my understanding there never was much of
 a difference between halt and poweroff.

I'm not quite clear what you are saying, but if you are saying that there is 
not give much difference in the English meaning of the words poweroff and 
halt, then I must take issue with you.  

Halt simply means stop.  Poweroff means turn the power off.  A big difference 
in the words.  Think of a car at traffic lights.  You stop it: halt it.  You 
do not power off, i.e. turn the engine off.  (Unless you accidentally stall 
it!)

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140813.14258.lisi.re...@gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

On 8/13/14, Tom H tomh0...@gmail.com wrote:
On Tue, Aug 12, 2014 at 10:50 AM, Zenaan Harkness z...@freedbms.net wrote:

Debian sid

systemd currently fails to poweroff for me

XFCE (appears to) exit, the mouse point shows
for a while, then the kernel/ shutdown log appears.

The last message is:
A stop job is running for Session 2 of user me

Red asterisks (up to 3) appear to oscillate at left
edge in an ascii wait for me animation.

Requires hard powercycle to poweroff.

How might I debug this?

https://lists.debian.org/debian-user/2014/07/msg01108.html

I've been assuming that the Debian maintainers had backported the fix
to (1) in the link above, but perhaps not. I haven't experienced this
though and you seem to be the first to report this on the list in
spite of many seemingly using systemd in testing and unstable,
willingly or not.

For me, it seemed to start happening after a sid update a week or may
be two ago. That's not useful for any pinpointing, but my sid update
from yesterday did not relieve the issue.

On 8/13/14, Javier Barroso javibarr...@gmail.com wrote:
On Tue, Aug 12, 2014 at 5:16 PM, Hugo Vanwoerkom hvw59...@care2.com
wrote:
Right. Debian Sid. 'halt' does not poweroff with systemd.
I think this behaviour has changed from pre-systemd era.

For the record, I am using XFCE's Shutdown button (near the logout,
sleep etc buttons).

Also, I came across the halt/poweroff thing quite a while back when
others did too, so when from cmd line I do use sudo poweroff now,
rather than halt.

I too used to always use halt command. But not any more :)

But in this instance, I'm trying to shutdown from XFCE standard gui.

Thanks,
Zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caosgnsse8b4hnsmyqntwnqcmfbh6svhnnrbs4gpaww30fvf...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER

On 8/13/14, Michael Biebl bi...@debian.org wrote:
 The last message is:
 A stop job is running for Session 2 of user me

 Red asterisks (up to 3) appear to oscillate at left
 edge in an ascii wait for me animation.

eye of cylon (thanks to who mentioned that)

 Have you waited at least 90 secs, which is the default timeout?

No, I shall make sure I do, next time I reboot.

But you know what my immediate next question would
then be regardless: how can I stop the 90s from occurring?

I tried CTRL-C, that did not work.

I tried CTRL-ALT-F2, and that was just a blank screen (although again,
perhaps I didn't wait long enough - I shall do so next time, to make
sure, I thought I did and that consoles were no longer starting, but
I'll wait a good minute or two next time).

Also for the record I tried these things before starting this thread:

0) apt-get dist-upgrade

1) Reboot, then log in at console, then sudo poweroff.
This 'worked'.

2) Reboot, console log in, then startx - actually this function 'se'
I put into my env, pursuant to help from helpful people on this list a
while back:
se=() {
 local tty_num=$(tty | grep -oE '[0-9]+$');
 startx -- -logverbose 7 vt$tty_num  /var/tmp/my_xorg.log;
 exit
}
and then XFCE gui 'logout'.
This worked, now back at console login prompt, log in, sudo poweroff.
This worked.

3) Finally, similar to 2), but XFCE gui 'poweroff' (instead of logout).
This worked.

So it seems there's something during my sessions which is failing to
stop properly when shutting down.

I really only run xterms, firefox and occasionally vlc, and sometimes
suspend (not hibernate).

I guess I should see if startx (xfce), suspend, unsuspend, poweroff
produces the problem.

Will get back to the list next time I reboot.

Thanks,
Zenaan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOsGNSRn0Cq8qGPPPDvXFTrO3=igaj93_3riobled3frfd7...@mail.gmail.com

Re: systemd fails to poweroff - A stop job is running for Session 2 of user $USER