Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Love systemd timers

blog.tjll.net

Post reply on HN
Print view View original

181–190 of 309 posts

Re: Love systemd timers

#181

Post by Cyph0n »

Eduard wrote: post #174
Cyph0n wrote: post #25

Earlier quoted context omitted.

+1, NixOS makes working with systemd a breeze. Defining units in Nix beats wrangling INI files. systemd.services.sync-recyclarr = { serviceConfig.Type = "oneshot"; path = [ pkgs.podman ]; script = '' podman exec -it recyclarr recyclarr sync radarr podman exec -it recyclarr recyclarr sync sonarr ''; }; systemd.timers.sync-recyclarr = { timerConfig = { OnCalendar = "daily"; Persistent = true; Unit = "sync-recyclarr.ser…

is this irony?

No. Is that not readable to you lol? I think anyone with even a passing familiarity with systemd would understand what that chunk of Nix is doing.

Compare it to the alternative of using plain systemd (including command(s) required to enable units).

Also, consider what build-time validation you get prior to starting the unit/timer. Hint: zero.

Re: Love systemd timers

#182

Post by gchamonlive »

gchamonlive wrote: post #93
happysadpanda2 wrote: post #87

Earlier quoted context omitted.

I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"

Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability

You could implement this with a gitlab instance in a separate system, like two VMs in proxmox or two physical machines, and a shell executor running in them. Gitlab CI has a nice feature to limit concurrency by using resource groups. Say you have 500 jobs spread through the day and the system stays offline for a while, when it comes online it'll start processing the jobs, but will only run a single one at a time. You get visibility, logs, queue monitoring and an API to query data.

Re: Love systemd timers

#183

Post by c-hendricks »

capitainenemo wrote: post #170
stryan wrote: post #45

Earlier quoted context omitted.

Should have been more clear: I use RandomizedOffsetSec= to add a random offset to a set start time (usually 4am), to prevent overloading the backup server, not truly random start times.

As someone else noted, that's also a cron feature

A feature of _some_ cron systems

Re: Love systemd timers

#185

Post by htx80nerd »

simoncion wrote: post #109

You will love SystemD [0] timers until they fuck you over in an entirely inscrutable way and the SystemD maintainers don't care to either fix the problem or update the docs to warn of the shortcoming. One of our customers called in with a production down incident caused by a full disk. We got a copy of the VM and took a look. Investigation revealed that / was full because /var/log was full and that our 'logrotate' ti…

>The conversation from the core devs ran through the pattern that one gets used to seeing when one runs into SystemD bugs that are caused by extremely complex unanticipated interactions between parts of the project

>SystemD contains an enormous -and ever-growing- amount of accidental complexity, and has a set of core maintainers who are generally disinterested in either documenting the places where one or more complex systems bind together to cause stop-the-world problems or fixing the systems involved so that they don't bind up.

excellent comment. thx for the long form. im sure it was fueled by excessive frustration.

imagine my surprise to learn that Systemd was causing my long standing frustration with changing my dns settings. and further surprise to learn that server admins have this same issue and many switch away from using systemd-resolved.

Re: Love systemd timers

#186

Post by OJFord »

kevinmgranger wrote: post #36
ramon156 wrote: post #27

Earlier quoted context omitted.

TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit

unit files barely have any nesting, so the INI-like format is already 90% of the way towards TOML, no?

I suppose some things that can be multiply specified would be arrays, and maybe there'd be a stronger argument for combining say timer & service in the same file (or that it could be optional) given some structure.

Personally though I'm not really a fan of TOML when the data is highly structured - prefer YAML even a lot of the time for some visual indication. (If I were writing a parser, I have zero doubt I'd rather parse TOML!)

Re: Love systemd timers

#188

Post by tpmoney »

Fire-Dragon-DoL wrote: post #167
LaSombra wrote: post #159

Earlier quoted context omitted.

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

Why the @?

Systemd lets you create templates that take an argument in from the scheduled service. It gets that from the value after the @. So you can write a unit file that schedules a task to run say every 3 days and in that unit file reference `jobs/%i`, then put your task in a file in jobs and say `systemctl start every-3-days@script1.sh` to run `script1.sh` on your schedule without needing to create a new unit file for each script. StepCA has a nice write up on their site about using these templates to schedule cert renewals for any arbitrary service

Re: Love systemd timers

#189

Post by eichin »

mkesper wrote: post #70

There's another big feature: You're not relying on the time zone to which the server was set (like with cron) but can explicitly specify a time zone: https://www.freedesktop.org/software/systemd/man/latest/syst...

hmm, when did that get added? Last time I checked, the only timezone you could specify was UTC (which was one more than cron supported, but still insufficient.)

Re: Love systemd timers

#190

Post by BrenBarn »

I like these systemd things but I always find it annoying how I have to create multiple separate files (like a file for the service and another for the timer, or similar if I need a socket file). In theory this is more flexible but in practice it's vanishingly rare that I need the same service to be accessible to more than one timer. It would be nice if there were some alternative compound format that could combine the timer and service into one.
Post reply on HN