Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
Hello Kyungmin, Kyungmin Park [2015-04-21 9:21 +0900]: 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. I'm not at all convinced that this is a good strategy. For maximum efficiency you *do* want to let apps stay in RAM/in the background as long as you have enough memory, so that they don't need to re-load/link/initialize when you call them again. So regular time-based sweeps are too aggressive here and lead to unnecessary app starts (which take a lot more CPU/battery than a simple context switch). On the other hand, if you start a new app and it doesn't get enough RAM, you want/need to start killing existing background apps oldest-to-newest (or perhaps biggest-to-smallest) until you have enough RAM again, but that needs to happen immediately. You don't want to wait until the next idle counter timer for this to happen. Finally, waking up the device every 30 s to clean up idle apps takes CPU/battery by itself. So I see no use case for idle timer based cleanup. Can you please explain why they are better than on-demand cleanup? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
My two cents is feature can be implemented as long as we get support from the application. For example sd-event has the builtin support to quit when it is idle. Systemd can pass the exit-on-idle timeout to the application via env variables so the event loop can configure itself to quit. I am not sure if glib event loop has this functionality already but I would be very interested to have it. I am just waiting for kdbus. Exiting on non-kdbus is still racy if we don't let systemd know upfront. Umut On Mon, Apr 20, 2015 at 5:10 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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! Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, Apr 21, 2015 at 12:26 AM, Martin Pitt martin.p...@ubuntu.com wrote: So I see no use case for idle timer based cleanup. Can you please explain why they are better than on-demand cleanup? We do it on Pantheon's infrastructure because many daemons have a resource footprint that is more than just allocated memory, like waking themselves up for cache cleanup or inefficient polling on sockets. We shut down socket-activated applications after an hour of idle time, and it dramatically frees up server resources for active daemons. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, 21.04.15 07:56, Kyungmin Park (kmp...@infradead.org) wrote: On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, Apr 21, 2015 at 8:37 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 21.04.15 07:56, Kyungmin Park (kmp...@infradead.org) wrote: On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, Apr 21, 2015 at 12:10 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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? Thank you, Kyungmin Park ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Tue, 21.04.15 09:21, Kyungmin Park (kmp...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
This will be nice to have.
On Mon, Apr 20, 2015 at 10:56 AM WaLyong Cho walyong@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.
---
src/core/load-fragment-gperf.gperf.m4 | 2 +
src/core/service.c| 97
+++
src/core/service.h| 5 ++
src/core/unit.h | 1 +
4 files changed, 105 insertions(+)
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 5305984..60d573e 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -229,6 +229,8 @@ Service.BusName,
config_parse_bus_name, 0,
Service.FileDescriptorStoreMax, config_parse_unsigned, 0,
offsetof(Service, n_fd_store_max)
Service.NotifyAccess,config_parse_notify_access, 0,
offsetof(Service, notify_access)
Service.Sockets, config_parse_service_sockets, 0,
0
+Service.ExitOnIdle, config_parse_bool, 0,
offsetof(Service, exit_on_idle)
+Service.ExitOnIdleSec, config_parse_sec, 0,
offsetof(Service, exit_on_idle_usec)
m4_ifdef(`ENABLE_KDBUS',
`Service.BusPolicy, config_parse_bus_endpoint_policy, 0,
offsetof(Service, exec_context)',
`Service.BusPolicy, config_parse_warn_compat,
DISABLED_EXPERIMENTAL, 0')
diff --git a/src/core/service.c b/src/core/service.c
index fa818fc..c8752ae 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -91,6 +91,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
static int service_dispatch_io(sd_event_source *source, int fd, uint32_t
events, void *userdata);
static int service_dispatch_timer(sd_event_source *source, usec_t usec,
void *userdata);
static int service_dispatch_watchdog(sd_event_source *source, usec_t
usec, void *userdata);
+static int service_dispatch_exit_on_idle_timer(sd_event_source *source,
usec_t usec, void *userdata);
static void service_enter_signal(Service *s, ServiceState state,
ServiceResult f);
static void service_enter_reload_by_notify(Service *s);
@@ -108,6 +109,8 @@ static void service_init(Unit *u) {
s-socket_fd = -1;
s-bus_endpoint_fd = -1;
s-guess_main_pid = true;
+s-exit_on_idle = false;
+s-exit_on_idle_usec = 0;
RATELIMIT_INIT(s-start_limit,
u-manager-default_start_limit_interval,
u-manager-default_start_limit_burst);
@@ -279,6 +282,56 @@ static void service_release_resources(Unit *u) {
assert(s-n_fd_store == 0);
}
+static void service_stop_exit_on_idle_timer(Service *s) {
+assert(s);
+
+s-exit_on_idle_event_source =
sd_event_source_unref(s-exit_on_idle_event_source);
+s-exit_on_idle_timestamp = DUAL_TIMESTAMP_NULL;
+}
+
+static void service_start_exit_on_idle_timer(Service *s) {
+int r;
+
+assert(s);
+
+if (s-exit_on_idle_usec = 0)
+return;
+
+if (s-exit_on_idle_event_source) {
+r =
sd_event_source_set_time(s-exit_on_idle_event_source,
s-exit_on_idle_timestamp.monotonic + s-exit_on_idle_usec);
+if (r 0) {
+log_unit_warning(UNIT(s)-id, %s failed to reset
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+r =
sd_event_source_set_enabled(s-exit_on_idle_event_source, SD_EVENT_ON);
+} else {
+r = sd_event_add_time(
+UNIT(s)-manager-event,
+s-exit_on_idle_event_source,
+CLOCK_MONOTONIC,
+s-exit_on_idle_timestamp.monotonic +
s-exit_on_idle_usec, 0,
+service_dispatch_exit_on_idle_timer, s);
+if (r 0) {
+log_unit_warning(UNIT(s)-id, %s failed to add
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+r =
sd_event_source_set_priority(s-exit_on_idle_event_source,
SD_EVENT_PRIORITY_IDLE);
+}
+
+if (r 0)
+log_unit_warning(UNIT(s)-id, %s failed to install
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+static void service_reset_exit_on_idle_timer(Service *s) {
+assert(s);
+
+dual_timestamp_get(s-exit_on_idle_timestamp);
+
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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! Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
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.
---
src/core/load-fragment-gperf.gperf.m4 | 2 +
src/core/service.c| 97 +++
src/core/service.h| 5 ++
src/core/unit.h | 1 +
4 files changed, 105 insertions(+)
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 5305984..60d573e 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -229,6 +229,8 @@ Service.BusName, config_parse_bus_name,
0,
Service.FileDescriptorStoreMax, config_parse_unsigned, 0,
offsetof(Service, n_fd_store_max)
Service.NotifyAccess,config_parse_notify_access, 0,
offsetof(Service, notify_access)
Service.Sockets, config_parse_service_sockets, 0,
0
+Service.ExitOnIdle, config_parse_bool, 0,
offsetof(Service, exit_on_idle)
+Service.ExitOnIdleSec, config_parse_sec, 0,
offsetof(Service, exit_on_idle_usec)
m4_ifdef(`ENABLE_KDBUS',
`Service.BusPolicy, config_parse_bus_endpoint_policy, 0,
offsetof(Service, exec_context)',
`Service.BusPolicy, config_parse_warn_compat,
DISABLED_EXPERIMENTAL, 0')
diff --git a/src/core/service.c b/src/core/service.c
index fa818fc..c8752ae 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -91,6 +91,7 @@ static const UnitActiveState
state_translation_table_idle[_SERVICE_STATE_MAX] =
static int service_dispatch_io(sd_event_source *source, int fd, uint32_t
events, void *userdata);
static int service_dispatch_timer(sd_event_source *source, usec_t usec, void
*userdata);
static int service_dispatch_watchdog(sd_event_source *source, usec_t usec,
void *userdata);
+static int service_dispatch_exit_on_idle_timer(sd_event_source *source, usec_t
usec, void *userdata);
static void service_enter_signal(Service *s, ServiceState state, ServiceResult
f);
static void service_enter_reload_by_notify(Service *s);
@@ -108,6 +109,8 @@ static void service_init(Unit *u) {
s-socket_fd = -1;
s-bus_endpoint_fd = -1;
s-guess_main_pid = true;
+s-exit_on_idle = false;
+s-exit_on_idle_usec = 0;
RATELIMIT_INIT(s-start_limit,
u-manager-default_start_limit_interval,
u-manager-default_start_limit_burst);
@@ -279,6 +282,56 @@ static void service_release_resources(Unit *u) {
assert(s-n_fd_store == 0);
}
+static void service_stop_exit_on_idle_timer(Service *s) {
+assert(s);
+
+s-exit_on_idle_event_source =
sd_event_source_unref(s-exit_on_idle_event_source);
+s-exit_on_idle_timestamp = DUAL_TIMESTAMP_NULL;
+}
+
+static void service_start_exit_on_idle_timer(Service *s) {
+int r;
+
+assert(s);
+
+if (s-exit_on_idle_usec = 0)
+return;
+
+if (s-exit_on_idle_event_source) {
+r = sd_event_source_set_time(s-exit_on_idle_event_source,
s-exit_on_idle_timestamp.monotonic + s-exit_on_idle_usec);
+if (r 0) {
+log_unit_warning(UNIT(s)-id, %s failed to reset
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+r = sd_event_source_set_enabled(s-exit_on_idle_event_source,
SD_EVENT_ON);
+} else {
+r = sd_event_add_time(
+UNIT(s)-manager-event,
+s-exit_on_idle_event_source,
+CLOCK_MONOTONIC,
+s-exit_on_idle_timestamp.monotonic +
s-exit_on_idle_usec, 0,
+service_dispatch_exit_on_idle_timer, s);
+if (r 0) {
+log_unit_warning(UNIT(s)-id, %s failed to add
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+r = sd_event_source_set_priority(s-exit_on_idle_event_source,
SD_EVENT_PRIORITY_IDLE);
+}
+
+if (r 0)
+log_unit_warning(UNIT(s)-id, %s failed to install
exit-on-idle timer: %s, UNIT(s)-id, strerror(-r));
+return;
+}
+
+static void service_reset_exit_on_idle_timer(Service *s) {
+assert(s);
+
+dual_timestamp_get(s-exit_on_idle_timestamp);
+service_start_exit_on_idle_timer(s);
+}
+
static void service_done(Unit *u) {
Service *s = SERVICE(u);
@@ -518,6 +571,7 @@ static void
Re: [systemd-devel] [RFC] core: introduce ExitOnIdle= and ExitOnIdleSec=
On 04/21/2015 12:10 AM, Lennart Poettering wrote: On Mon, 20.04.15 23:56, WaLyong Cho (walyong@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. That's why I sent with [RFC] prefix. :) Thanks for reply. WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
