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