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

[Lennart Poettering]

On Tue, 21.04.15 09:21, Kyungmin Park (kmpark at infradead.org) wrote:

> > 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?
> >
> 
> Note that it's different story from original mail concept. I just
> explain my requirement.
> 
> At mobile. some daemon is not doing exact daemon task. it acts like
> app. so it's kill-able based on priority. now it can't know it's idle
> or not. In the app-like daemon developer, they don't want to exit
> since performance reason. but in the view of system admin, it's
> resource waste. it's better to kill if it know it's idle. Of course
> there are assumption it's activated by other way. so it's no problem
> to kill it at idle time.
> 
> if app-like daemon doesn't give any hints, it doesn't know it and
> can't handle it. but systemd know it and send idle information. it
> would be helpful.
> IOW, it's required to know some daemon is idle or not. and systemd is
> proper place to know it.

Well, but systemd does not actually know it, and can't know it.

I mean, consider a word processor app. A good word processor app should
make recovery copies of edited documents every now and then as long as
the the document is not properly saved. Now, let's say the timer for
this is set by the word processor to 30s after the last edit. Now, you
configure systemd to kill it 20s after the last time it consumed any
CPU. With an automatic killing logic in systemd you'd completely break
the recovery logic, because it would kill before the app's own timer.

It's really only the app that knows when it is really idle.

I mean I can see that for app schemes different policies might apply
than to system daemons, but I doubt it's as simple as "didn't consume
any CPU in the last 30s"... Instead it could be something like "we are
under memory pressure and app is not in the fg and didn't take a kill
inhibitor lock" or something like that (which is very close to what
android actually does), however, something like that is considerably
more complex than what you propose, and i am not sure whether systemd
is really the right place to implement a logic like that...

Lennart

-- 
Lennart Poettering, Red Hat