On 12/02/2015 10:49 AM, David Wright wrote:
On Wed 02 Dec 2015 at 11:06:09 (+0000), 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.
