Cron vs. Systemd .timer - strong limitation for inactive sessions

lynix · 2015-09-03 06:45:29

I recently came across something that seems like a very strong limitation, when migrating from Cron to Systemd .timer units:

If I got it right, the equivalent of a regular user's crontab should be .timer units defined in the user instance of systemd (systemctl --user). My problem with this is, that the user instance (afaik) is not running when the user is not logged in, so the timer would not be triggered then. While this might be no problem on desktops, it surely is on servers.

What makes it even worse is the fact that you cannot just convert the user crontabs to system .timer units and have them configured via environment files, e.g.

[Unit]
Description=User crontab (profile %i)
After=network.target

[Service]
Type=simple
EnvironmentFile=/etc/conf.d/crontab-%i
ExecStart=/usr/bin/sh $command
User=$user

[Install]
WantedBy=multi-user.target

This does not work as you cannot use variables in 'User='.

Did I get something wrong? How would you migrate (user) crontabs to .timer units? (or would you at all?)

Last edited by lynix (2015-09-03 06:45:58)

rumpelsepp · 2015-09-03 07:17:14

To ensure that systemd --user is running without an active session you just have to linger your user: https://sevenbyte.org/2014/11/15/cron-j … timer.html

It is in the last paragraph, sorry for being not more verbose, just on the phone.

graysky · 2015-09-03 07:32:06

Good tip [linger]. Should be added to the wiki if not already there.

rumpelsepp · 2015-09-03 08:08:20

it is: https://wiki.archlinux.org/index.php/Sy … _instances

lynix · 2015-09-03 08:13:09

Thanks for the tip with lingering the user

But doesn't this run all user-defined units then? Lets say I have a .timer that performs backups, this should run even if I'm not logged in, but a .service starting autossh for a tunnel should only be run if I'm actually logged in on the machine and doing stuff. So how can we distinguish between the .timer and autossh.service?

rumpelsepp · 2015-09-03 08:29:37

That's an interesting question; I guess that is not possitble atm. I think I will ask that on the systemd mailing list (unless somebody is faster than me).

lynix · 2015-09-03 16:52:39

Go ahead, I'm curious to find out what they say to this!

Another thing I noticed is the following: having logged out of my Xorg session, the daemons started in the user instance of systemd (e.g. autossh) are not killed. Maybe I have to issue a 'systemctl --user exit' before performing the actual logout.

Leonid.I · 2015-09-04 17:05:12

lynix wrote:

Did I get something wrong? How would you migrate (user) crontabs to .timer units? (or would you at all?)

Exactly, why would you? Think of it this way: systemd provides poor-man versions of various tools (cron, syslog, LXC). These versions are meant to be limited and are not intended to be useful in complex situations ("complex" is of course a matter of perspective). In your case, just use cron and don't waste time on systemd-timers...

lynix · 2015-09-04 18:35:14

Leonid.I wrote:

Exactly, why would you? Think of it this way: systemd provides poor-man versions of various tools (cron, syslog, LXC). These versions are meant to be limited and are not intended to be useful in complex situations ("complex" is of course a matter of perspective). In your case, just use cron and don't waste time on systemd-timers...

With all respect, I strongly disagree: journald, in my opinion, is far more powerful than syslog-ng, with all its meta-information and flexible handling of volatile system logs. systemd-timers, apart from the limitation we are talking about, are as powerful as fcron concerning time-based triggering already, and I don't think development will stop here. I can't say anything about LXC by now, as I've never used them.

Time will tell what's on systemd creator's minds, but I wouldn't say these mechanisms are meant to be poor-man versions...

Raynman · 2015-09-04 20:05:44

lynix wrote:

But doesn't this run all user-defined units then? Lets say I have a .timer that performs backups, this should run even if I'm not logged in, but a .service starting autossh for a tunnel should only be run if I'm actually logged in on the machine and doing stuff. So how can we distinguish between the .timer and autossh.service?

If you install everything as a dependency of the default.target, then yes, they will all run. A basic setup for this scenario could define a login.target. Then make this start when you log in (could just be `systemctl --user start login.target` in a login script) and go back to only the non-login units at the end of your session with

$ systemctl --user isolate default.target

Arch Linux

#1 2015-09-03 06:45:29

Cron vs. Systemd .timer - strong limitation for inactive sessions

#2 2015-09-03 07:17:14

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#3 2015-09-03 07:32:06

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#4 2015-09-03 08:08:20

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#5 2015-09-03 08:13:09

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#6 2015-09-03 08:29:37

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#7 2015-09-03 16:52:39

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#8 2015-09-04 17:05:12

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#9 2015-09-04 18:35:14

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

#10 2015-09-04 20:05:44

Re: Cron vs. Systemd .timer - strong limitation for inactive sessions

Board footer