Re: systemd unit timer

[Uoti Urpala <uoti.urpala@xxxxxxxxxxx>]

On Mon, 2020-08-10 at 20:19 +0100, Dave Howorth wrote:
> On Mon, 10 Aug 2020 20:21:51 +0200
> Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> > i.e. it unifies how system programs are invoked, and that's a good
> > thing. it turns time-based activation into "just another type of
> > activation".
> 
> Most of that has gone over my head so some examples would probably help
> me to understand. Perhaps they're in the git logs?
> 
> But I'm not normally running system code in cronjobs. I usually run
> either scripts I have written myself, or backup commands and the like.

Even many of the simplest scripts will most likely benefit from basic
systemd unit functionality like having correct journal metadata
("something logged from foo.service" as opposed to "something logged
from (child process of) cron.service").


> If I wanted to run a service, presumably I could just write a 'manual'
> invocation as a cron or at job? I'm not seeing the big imperative to
> create another new bunch of code to learn and maintain. I expect I'm
> blind.

You can view "running code at a specified time" as having two parts:
choosing the time when to start it, and the general ability to run code
in a specified environment (user, sandboxing, resource limits,
dependencies, etc). Cron does the first, but systemd units do the
second a lot better. If you want to have support for both, you either
need to add most of the stuff in systemd units to cron, or timer units
to systemd. The second is a much saner option.

Basically, you want to have support for everything in unit files also
for code that is started based on time. This means that having cron
directly running code is not a real option. And having cron running
"systemctl start" commands is kludgey and has enough problems to
justify native timer units.


_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel