Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> schrieb: >> No, you need to wrap your command with it. I.e. instead of >> >> ExecStart=/path/to/backup-command ... >> >> you use >> >> ExecStart=/usr/bin/systemd-inhibit /path/to/backup-command ... > Right. Not too bad, but Inhibits=sleep sounds nice.
I probably try that, thou I'd prefer an extra configuration option for it because in the jobs monitor it would show me systemd-inhibit as the running process instead of my backup script. >> What a pity. Are there any deeper plans on that one? I think it should >> not be too difficult to implement and if I had some time I would try it. >> But I don't like inventing all the complex surrounding this may bring in, >> read as: Is there a list / brainstorming of what one had to consider and >> take care of? While documentation of systemd is very good and easy to >> follow, I find it difficult to find documentation of implementation >> details and feature plans (yes, there are the blogs but those seem to >> cover thoughts about already implemented features)... > Yes, it seems that basically changing the timer type would do the trick. > One thing which worries me, is the issue the "laptop in the bag" issue. > But maybe we would just need to document the fact that setting the timer > to need to make sure that the computer will not be in hostile surrounding. > OTOH, it might make sense to add a new inhibition: 'alarms', > which you could set *before* suspending, which would prevent > CLOCK_REALTIME_ALARM timers from firing. Your "laptop in a bag" example is that kind of brainstorming I was thinking of. Of course, such an option to resume from sleep should always be opt-in, never opt-out. So, if we had such a new timer type, systemd should have a switch to actually behave this way and default to fall-back behavior (not waking the system). That way, an energy profile in desktop environment could control this switch: Set your profile to "desktop" and it will opt-in to wake timers, set it to "laptop" or "mobile", and it won't opt-in. If battery is below some threshold it sould also not opt-in. My use case is a desktop PC so I didn't think of such issues. I don't like the fact to solely rely on an inhibition "alarms" because that would means it'd be opt-out only. In my opinion it needs to be opt-in. -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
