upvote

points

by jerf2 hours ago |
comments
upvoteby pkal1 hours ago|
next
[-]
I am familiar with the syntax, so I am biased ("*/3" and "12,14,20" makes sense if you are familiar with Unix tools), but it is still more intuitive to me than the systemd unit file syntax and usage. I know that I just have to edit /etc/cron or throw any executable file into /etc/cron.d/monthly and it will work on my system, but I cannot write a systemd timer file from scratch without looking it, and to do that I first have to find the directory where the other examples are located. /etc/systemd doesn't appear to be it.

This is generally my only real complaint about systemd. I don't care if it is too monolitic, written in C or whatever, I just want a straightforward syntax for straightforward operations. I'd like it if systemd could recognize if a .target file is a shell script and just do "the right thing". Perhaps it would make sense for a timer file to recognize cron syntax as well. Or at least allow for a kind of extensibility so that I can have it supported.

If systemd had a little more respect for existing conventions, I am pretty sure it wouldn't be so controversial. After all, system administrators like it because they use it all the time, but a regular, full-timer user like me, who only deals with it when something is broken or have to use it as a means-to-an-end to set something up, then all friction is annoying and bad UX. (And no, using Nix is not the solution)

reply
upvoteby LaSombra41 minutes ago|
parent|
next
[-]
If you want to create a new systemd unit file you can run:

   $ sudo systemctl edit --force --full my-scheduled-work@.timer
or

   $ systemctl edit --user --force --full my-scheduled-work@.timer
reply
upvoteby Fire-Dragon-DoL8 minutes ago|
parent|
[-]
Why the @?
reply
upvoteby krunck1 hours ago|
parent|
prev|
[-]
Yeah, it would be nice to have a folder like /etc/systemd-jobs/ where I could put them and where there are no files unrelated to job scheduling. There is /etc/systemd/user, but it does get a bit of pollution depending on the system.
reply
upvoteby ralferoo43 minutes ago|
parent|
[-]
Not sure if you're talking about cron or systemd, but cron definitely has that in /etc/cron.d where you can have arbitrary crontabs, or /etc/cron.{hourly|daily|weekly|monthly} where you can just place arbitrary scripts if you don't care exactly when they run, just the frequency.
reply
upvoteby eqvinox2 hours ago|
prev|
[-]
How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.
reply
upvoteby max-privatevoid15 minutes ago|
parent|
next
[-]
It's a mystery to me why everyone tries to use OnCalendar here, when "n amount of times within a certain timeframe" can be done much more easily with OnActiveSec, in this case that'd be OnActiveSec=6h.
reply
upvoteby iam-TJ1 hours ago|
parent|
prev|
next
[-]

  $ systemctl cat public-inbox-watch@.timer
  # /etc/systemd/system/public-inbox-watch@.timer
  [Unit]
  Description=Periodic fetch of public mailing list

  [Timer]
  # twice a day
  OnCalendar=*-*-* 5,17:35
  RandomizedDelaySec=1h
  Persistent=true

  [Install]
  WantedBy=multi-user.target
reply
upvoteby PenguinCoder35 minutes ago|
parent|
next
[-]
So the `OnCalendar` stanza is the same as a Cron job; without the helpful comments of the ordering? And that is considered _easier_??

Just use Cron. It does one thing and does it well.

reply
upvoteby eqvinox1 hours ago|
parent|
prev|
[-]
I, er, what? It's... the same as cron? I'm confused now. It's not exactly the same, I guess?
reply
upvoteby ecnahc5151 hours ago|
parent|
prev|
next
[-]
Something like:

    OnCalendar=00/6
You can test it with:

    systemd-analyze calendar --iterations=6 '0/6:00:00'
The format is `DayOfWeek Year-Month-Day Hour:Minute:Second`

https://www.freedesktop.org/software/systemd/man/latest/syst...

reply
upvoteby simoncion1 hours ago|
parent|
prev|
next
[-]
Sure, I'll pile on here. To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example:

  Mon,Fri *-01/2-01,03 *:30:45
Who'd ever want to go back crontab format for nontrivial scheduling? [1]

[0] <https://www.freedesktop.org/software/systemd/man/latest/syst...>

[1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.

reply
upvoteby p03581 hours ago|
parent|
[-]
If you know the syntax, it's still actually rather trivial. Still easier to read than advanced cron magic.
reply
upvoteby simoncion55 minutes ago|
parent|
[-]
> Still easier to read than advanced cron magic.

Looking at the other examples on that page, I'm gonna say that it's only arguably easier to read for basic stuff... especially if you're familiar with the syntax. The complex stuff is -at best- just as difficult.

reply
upvoteby PunchyHamster1 hours ago|
parent|
prev|
[-]
That's simple but consider "run something 4x per day but randomize a delay by hour so all of the 200 servers doing that task won't run it all at once"

In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command

In systemd timers, it's just

    OnCalendar=0/6:00:00
    RandomizedOffsetSec=60m
and the offset generated will be stable for the job on a given machine (i.e. always same on this machine but different on others) so you will get nice uniform distribution of load.

If you add

    Persist=true
the job will also be run once if there was one or more scheduled runs when the machine was down
reply
upvoteby PenguinCoder33 minutes ago|
parent|
next
[-]
`* 1 * * * sleep $(( $(od -N1 -tuC -An /dev/urandom) \% 45 ))m ; <your command here>`
reply
upvoteby simoncion1 hours ago|
parent|
prev|
[-]
> In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command

Nope. From crontab(5)

  The  RANDOM_DELAY variable allows delaying job startups by random amount
  of minutes with upper limit specified by the variable. The random  scal‐
  ing  factor  is  determined during the cron daemon startup so it remains
  constant for the whole run time of the daemon.
That's from my cronie install, but it looks like this has been a feature of some crons for at least a decade. (Notice that the post date of [0] is in 2016.) Given that cronie is based on vixie-cron, and I think I was was using vixie-cron in 2002, I bet it's been a thing for at least twenty years.

[0] <https://stackoverflow.com/a/34815984>

reply