6 ms·

systemd requiring two files for timers is quite intentional. A timer runs a unit. Which means that you can test any timer easily by just starting the unit itse

systemd requiring two files for timers is quite intentional. A timer runs a unit. Which means that you can test any timer easily by just starting the unit itself whenever needed. With cron, to test things you need to fiddle with the configuration and schedule it to run in the next minute or two, wait, check the logs, adjust, rinse and repeat.

twic 3y ago
systemd could just support the Timer section in unit files. You could then still start the unit file manually.
- its-summertime 3y ago
  you can run the unit and run the timer, if you start the combined unit, then should it run it as a service or as a timer? and then you can have multiple timer files for a single service too
  - twic 3y ago
    It would run as a service. You don't 'systemctl start' a timer as things stand now, so it's perfectly clear what that should do. If you want to have a separate timer unit, or several of them, fine. But you shouldn't have to.
- chasil 3y ago
  By that logic, why not bring more types of entries into the service file? Path units for inotify triggers, mount units for NFS automounts active only when the service is running, socket units that register network triggers, all of these might have some use. It might seem cumbersome, but I do agree that configuring complex activity sometimes means many unit files. Timer units would be a clear example.
  - twic 3y ago
    > sometimes You have identified the key point, thank you. Sometimes, things are complicated enough that you want to break configuration up into multiple units. But not always. At the moment, systemd forces you to always break it up, even when that does more harm than good.
tetha 3y ago
This is also pretty useful if you use parametrized unit files. For example, most of our long term archiving is implemented in a parametrized systemd unit `push-to-archive@`. So in order to backup a new dataset, you deploy the config for it, add a simple systemd timer triggering `push-to-archive@newdataset` and that's it. Simple and even readable in the systemd timer status.
- christophilus 3y ago
  Wow. Somehow, I didn’t know about the @ thing. That’s super handy. I have a few deployments to simplify the next time I have to touch them.
networked 3y ago
Fcron's approach is to provide a shell where you can examine, run, renice, and kill cron jobs: http://fcron.free.fr/doc/en/fcrondyn.1.html http://fcron.free.fr/doc/en/fcrondyn.1.html. (You can run a job either independently or instead of the next scheduled run.) I think this is competitive with what systemd provides by separating the service from the timer. (Edit: I mean in this area. As a sibling comment points out, the separation also enables parametrization.) An advantage that systemd has is that you can refer to a service by a meaningful name instead of a numeric job identifier. What I would like to have in fcron is the ability to direct the job's output to the console when running a job immediately.
e12e 3y ago
> A timer runs a unit. Which means that you can test any timer easily by just starting the unit itself whenever needed. With cron, to test things you need to fiddle with the configuration and schedule it to run in the next minute or two, wait, check the logs, adjust, rinse and repeat. Not sure if I understand - a Cron "unit" is just a command that runs in a clean environment - you can test that without Cron. SystemD require a "unit" wrapper around your command line - and is tricky to test without systemD? (No copy paste of the command and arguments - you would have to manually parse the ini file back into a command line).
- hotnfresh 3y ago
  It can take a little effort to run a command under the same environment it’ll have when cron runs it—copy-paste isn’t a full description of what you have to do. And it’s pretty easy to get wrong, then not find out until your job fails.
- Denvercoder9 3y ago
  > Not sure if I understand - a Cron "unit" is just a command that runs in a clean environment - you can test that without Cron. It's not that easy to do. I've wasted hours in an old life figuring out that cron ran my scripts with a different $PATH than `env -i` did. systemd timers/units on the other hand are executed through the exact same code path, so if `systemctl start` works, you can be sure it works when started by a timer too.
c7DJTLrn 3y ago
The complaints about systemd timers seem strange. To me, they're a sysadmin's dream to work with. I can see exactly when the last trigger was, when the next one will be, and I can test that the unit will work properly when it fires. And I don't have to remember cron syntax. As for them not supporting email, if you really need to you can add an OnFailure= to the service unit to send one.
MatthiasPortzel 3y ago
I’m a systemd fan, but managing unit files is definitely a pain. The units and timers I’ve written get thrown in `/lib/systemd/system` (or `/etc/systemd/system/`, who knows) along with a ton of the OS’s unit files.
- mekster 3y ago
  Does it matter where it goes when you can edit with `edit` sub command?
  - MatthiasPortzel 3y ago
    I didn’t know about the edit sub command, that may be helpful. But it doesn’t solve two of my other use cases: listing all unit files written by me, and version controlling or backing up unit files.

twic 3y ago

systemd could just support the Timer section in unit files. You could then still start the unit file manually.

its-summertime 3y ago
you can run the unit and run the timer, if you start the combined unit, then should it run it as a service or as a timer? and then you can have multiple timer files for a single service too
- twic 3y ago
  It would run as a service. You don't 'systemctl start' a timer as things stand now, so it's perfectly clear what that should do. If you want to have a separate timer unit, or several of them, fine. But you shouldn't have to.
chasil 3y ago
By that logic, why not bring more types of entries into the service file? Path units for inotify triggers, mount units for NFS automounts active only when the service is running, socket units that register network triggers, all of these might have some use. It might seem cumbersome, but I do agree that configuring complex activity sometimes means many unit files. Timer units would be a clear example.
- twic 3y ago
  > sometimes You have identified the key point, thank you. Sometimes, things are complicated enough that you want to break configuration up into multiple units. But not always. At the moment, systemd forces you to always break it up, even when that does more harm than good.

tetha 3y ago

This is also pretty useful if you use parametrized unit files. For example, most of our long term archiving is implemented in a parametrized systemd unit `push-to-archive@`. So in order to backup a new dataset, you deploy the config for it, add a simple systemd timer triggering `push-to-archive@newdataset` and that's it. Simple and even readable in the systemd timer status.

christophilus 3y ago
Wow. Somehow, I didn’t know about the @ thing. That’s super handy. I have a few deployments to simplify the next time I have to touch them.

networked 3y ago

Fcron's approach is to provide a shell where you can examine, run, renice, and kill cron jobs: http://fcron.free.fr/doc/en/fcrondyn.1.html http://fcron.free.fr/doc/en/fcrondyn.1.html. (You can run a job either independently or instead of the next scheduled run.) I think this is competitive with what systemd provides by separating the service from the timer. (Edit: I mean in this area. As a sibling comment points out, the separation also enables parametrization.) An advantage that systemd has is that you can refer to a service by a meaningful name instead of a numeric job identifier. What I would like to have in fcron is the ability to direct the job's output to the console when running a job immediately.

e12e 3y ago

> A timer runs a unit. Which means that you can test any timer easily by just starting the unit itself whenever needed. With cron, to test things you need to fiddle with the configuration and schedule it to run in the next minute or two, wait, check the logs, adjust, rinse and repeat. Not sure if I understand - a Cron "unit" is just a command that runs in a clean environment - you can test that without Cron. SystemD require a "unit" wrapper around your command line - and is tricky to test without systemD? (No copy paste of the command and arguments - you would have to manually parse the ini file back into a command line).

hotnfresh 3y ago
It can take a little effort to run a command under the same environment it’ll have when cron runs it—copy-paste isn’t a full description of what you have to do. And it’s pretty easy to get wrong, then not find out until your job fails.
Denvercoder9 3y ago
> Not sure if I understand - a Cron "unit" is just a command that runs in a clean environment - you can test that without Cron. It's not that easy to do. I've wasted hours in an old life figuring out that cron ran my scripts with a different $PATH than `env -i` did. systemd timers/units on the other hand are executed through the exact same code path, so if `systemctl start` works, you can be sure it works when started by a timer too.

c7DJTLrn 3y ago

The complaints about systemd timers seem strange. To me, they're a sysadmin's dream to work with. I can see exactly when the last trigger was, when the next one will be, and I can test that the unit will work properly when it fires. And I don't have to remember cron syntax. As for them not supporting email, if you really need to you can add an OnFailure= to the service unit to send one.

MatthiasPortzel 3y ago

I’m a systemd fan, but managing unit files is definitely a pain. The units and timers I’ve written get thrown in `/lib/systemd/system` (or `/etc/systemd/system/`, who knows) along with a ton of the OS’s unit files.

mekster 3y ago
Does it matter where it goes when you can edit with `edit` sub command?
- MatthiasPortzel 3y ago
  I didn’t know about the edit sub command, that may be helpful. But it doesn’t solve two of my other use cases: listing all unit files written by me, and version controlling or backing up unit files.