On Fri 11 Aug 2017 at 19:13:47 (+0200), Christian Seiler wrote: > Hi there, > > On 08/11/2017 06:29 PM, Dejan Jocic wrote: > > On 11-08-17, Christian Seiler wrote: > >> You can also set DefaultTimeoutStopSec= in /etc/systemd/system.conf > >> to alter the default for all units (though individual settings for > >> units will still override that).
That works great. I've set DefaultTimeoutStopSec=27s > > Thank you for suggestion. I did find that solution, some time ago, can't > > remember exactly where. But it was followed by warning that it is bad > > idea, can't remember exactly why. Do you have any hint of why it could > > be bad idea to limit timeout, or I've just misunderstood whatever I've > > read about it? > > Well, there's a reason the default is 90s. And for some services even > that might be too short. Take for example a database server where the > regular stop script might take 10 minutes to shut down properly (when > no error occurs). The problem only embarrasses me on laptops, eg leaving the house, boarding an aircraft, etc. Nothing important is running (I've already killed X and touched the power button) and the only alternative is forcing it off with the prolonged power button. It's worked well for a fortnight now. > The right timeout is always a balancing act - and systemd's default > is a compromise to provide something that won't break most use cases > but still cause the system to shut down after a finite time. There are some timeouts that are set to "no limit" but I haven't hit one of those for nearly a year. It's incomprehensible to me why "RPC portmapper replacement" needs to be shut down cleanly however long it takes. Likewise the "Color Profiles" manager which, while having a 90 second timeout to start with, would increment the timeout by another 90 seconds each time it expired, so it was effectively infinite. Cheers, David.
