Summary: | RFE: Add StopUnit= support to timers | ||
---|---|---|---|
Product: | systemd | Reporter: | Jim Carter <jimc> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED WONTFIX | QA Contact: | systemd-bugs |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Jim Carter
2014-06-01 05:57:58 UTC
> If the timer had a StopUnit option, baobei-umount.service would not be needed. Please don't use timers to shut down units after a guess a how long it takes for them to go idle. It's not safe and never will be. > I tried hard to set up socket activation for cups (printing), but failed. I wanted cups to be stopped a certain time after being started, but the timer triggered immediately and the killer service killed cups which had just been started. Fedora ships with CUPS using socket activation, so it definitely works. If CUPS should shut down on idle, that needs to be taken up with the CUPS project, not systemd. > If systemd's automount unit had an auto-unmount timer, a lot of this complication could be avoided. There is already a TODO ("automount: implement expire") for automount units to support unmount-on-idle, which is already implemented in the underlying autofs layer, as you note. > In fact, the same is true for socket units, for which you can assume that the underlying service is unused if no packets go through its socket. No, you cannot assume that. Your example service, CUPS, is a counterexample given that a brief connection requesting a huge print job could occupy the daemon for hours. > A race condition needs to be worked around, if systemd declares a unit unused and stops it, but after committing to stop, the automount reports access or the socket receives a packet. This should already be handled for socket activation. systemd resumes watching for incoming data when stopping the service, allowing for immediate reactivation after shutdown completes. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.