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

[Kyungmin Park]

On Tue, Apr 21, 2015 at 8:37 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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?
>

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.

Thank you,
Kyungmin Park