[systemd-devel] systemd unit timer

[Lennart Poettering]

On Mo, 10.08.20 20:19, Dave Howorth (systemd at howorth.org.uk) wrote:

> > It kinda makes sense to invoke cronjobs the same way as any other
> > piece of system code in userspace: as a service, so that you can take
> > benefit of deps management, priv handling, logging, sandboxing and so
> > on, so that you can run stuff either manually or by timers or by any
> > other kind of activation, and so on, and it always ends up in exactly
> > one instance. And there's tons of other stuff too.
> >
> > 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.

Well, by "system code" in this context I mean code running in system
code, i.e. not associated with a specific "human" user. i.e. all code
traditionally run from /etc/crontab and related dirs is in "system
context".

> 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.

I mean, you don't have to use systemd timers+services, that's entirely
up to you. cron continues to work after all.

However, there's a ton of stuff in it for you if you do bother running
stuff as timer. For example, let's say you wrote your own backup
script, that streams your whole OS backup to some server. Stuff like
that you want resource manage a bit, i.e. use CPUShares=100 or so to
make sure it doesn't take as much resources. You want to lock it down,
since it's interacting with the netwokr, and it's bad enough it needs
to be able to read all your files, but it sure as hell shouldn't also
be able to change them, so you could lock it down with ProtectSystem=
and so on. And sometimes you want to start a backup manually, outside
of your usual schedule, so there's "systemctl start" of the backup
script to do so in a way that won't conflict if the schedule hits
while the backup is still running. Then, maybe you need some service
to be up while you are doing your backup (or a mount), and it might be
used by something else too, but should go away when not used. You can
pull it in cleanly from your timer's service now, and mark it
StopWhenUnneeded= so that it goes away when no service uses it. And so
on and so on.

Lennart

--
Lennart Poettering, Berlin