[systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=

[Lennart Poettering]

On Tue, 21.04.15 07:56, Kyungmin Park (kmpark at infradead.org) wrote:

> On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Mon, 20.04.15 23:56, WaLyong Cho (walyong.cho at samsung.com) wrote:
> >
> >> If a service does not consume CPU during some time(can be configured
> >> by ExitOnIdleSec=) and set to stopped on idle state(ExitOnIdle=), the
> >> service will be stopped. This can be useful if the service provides
> >> some of activation methods.
> >
> > Hmm, I am not convinced this would be a good idea, sorry.
> >
> > The crux of the issue is that it is really hard to detect from the
> > outside if a daemon is really idle. Only the daemon itself knows
> > whether it is truly idle or not. I mean, it could just be waiting for
> > some timer to elapse, or some other external event.
> >
> > I doubt this is really useful unless you have really really simple
> > daemons that purely react on client requests and nothing else, and you
> > know the codebase and that it is OK to terminate the daemon just
> > because its CPU usage is zero. But if you know the codebase that well
> > it would probably be a better idea to just add support for
> > exit-on-idle directly to the daemon in question.
> >
> > exit-on-idle is really something that should be implemented *in* the
> > daemon, and not done externally!
> 
> then how about to change the concept? IdleNotifier?
> some daemon users said it's hard to know how long its idle so systemd
> give idle time by notification.
> It will save lots of codes. don't need to implement own timer for idle timeout.
> 
> it's match your comments. "It should be implemented *in* the daemon".
> when idle notification is comes. daemon decides exit or not. Of course
> daemon will implement defined idle notifier callback.
> 
> does it reasonable?

Well, we should make sure to not encourage people to write
suboptimal. And such an external timer-based notification is
necessarily suboptimal code: a well-behaving daemon would set a timer
the moment it notices it is idle, and then exit when that timer
elapses, and cancel the timer if it in between notices it's not idle
anymore. However, if we externally ping the daemon in external
intervals, then this is necessarily much earlier or later than
necessary...

Also, is there really much gained by this? I mean, if you want such a
notifier framework from systemd towards the daemon, then the daemon
needs to listen somehow on a socket/fifo/ipc object, accessible via an
fd. But if it does so it might as well listen on a timerfd directly,
which is also just an fd, and does not require anything like systemd
triggering it.

Hence I am not sure what we'd gain by a concept like that?

Lennart

-- 
Lennart Poettering, Red Hat