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

171–180 of 309 posts

Re: Love systemd timers

#171

Post by weaksauce »

krunck wrote: post #140
pkal wrote: post #127

Earlier quoted context omitted.

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 fir…

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.

you can organize them however you want on your system and then use symlinks to make them available.

there's also `systemctl --all list-timers` to view them.

Re: Love systemd timers

#172

Post by mike_hock »

thomashabets2 wrote: post #57

I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…

> What makes you say that? You can set the PATH right in the crontab.

OK but I don't want to hardcode $PATH in the crontab just so I can test the cronjob. Barring the hardcode, $PATH is one thing when cron runs and another when you try out the command yourself. systemctl start foo.service starts the command inside with the same environment as when the timer fires so you know it'll work the same.

On the flip side, your cron job will run at the time you specify in the crontab. Your systemd timer, on the other hand, may fire at the specified time (and most of the time, it will), but it can also suddenly stop firing once it has fired on a February 29th and then never fire again, due to logic bugs in systemd, or it may or may not fire when you "restart" the timer unit, due to logic bugs in systemd (that's when it only has OnCalendar, so yes, definitely a bug).

Re: Love systemd timers

#173

Post by keynha »

kayson wrote: post #65

I love systemd timers! I've slowly moved all of my ansible-deployed cron jobs to timers (now just an ansible copy!). The integration with journalctl, especially in a newer OS like Debian 13 where syslog is gone, is really nice. It's also really nice to be able to start the service manually for debug. Having a cron job that didn't work was an annoying exercise in copy/pasting or writing an extra shell script. Don't ev…

[dead]

Re: Love systemd timers

#174

Post by Eduard »

Cyph0n wrote: post #25
hombre_fatal wrote: post #9

NixOS comes with systemd, so I've been using it as a first-class part of managing stuff. It's great, especially coming from macOS' launchd. Which makes it nice to distribute a tool for NixOS so that it can lean into systemd instead of as some bolted-on afterthought. Makes me wonder what you'd do if you were distributing a lifecycle-heavy tool for Linux users in general since systemd isn't ubiquitous. I use a systemd…

+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?

Re: Love systemd timers

#175

Post by egorfine »

mschuster91 wrote: post #154
egorfine wrote: post #111

We have used cron perfectly fine for decades and it served us well within its very clear limitations. But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

> But now obviously we were so blind and wrong all this time and the only true solution is of course systemd. Come on, dude. That's unnecessarily polemic. cron et al have served us for decades, yes. But that doesn't mean that cron is the solution that needs to accompany us until the heat death of the universe or year 2038, whatever comes first. I agree, the systemd folks haven't exactly been the best when it comes to…

> that doesn't mean that cron is the solution that needs to accompany us until the heat

Yeah I agree.

> systemd folks haven't exactly been the best when it comes to PR

It's deeper than that. Systemd folks are enemies of Linux. First, it's "fuck your opinion, do as we say" attitude which makes me want to throw away everything that comes from that poisonous well. Second, it's the embrace and extinguish strategy employed by the systemd project. And third, systemd author is up to no good: https://news.ycombinator.com/item?id=46784572

Re: Love systemd timers

#176

Post by weaksauce »

the_real_cher wrote: post #56
lanycrost wrote: post #37

systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl

This is such a modern view. People used to HATE systemd when it first came out, but I always liked it and knew people would eventually come around and its nice to see they finally did!

the thing for me is I started using the init system and while it was fine it always felt brittle for some reason. systemd feels solid and robust like it was well thought out. maybe i'm off base and didn't know how to use init effectively but it was my feeling.

that and cron always felt fragile too with a lot of quirks and limitations you had to work around instead of being a robust thing from the start.

Re: Love systemd timers

#177

Post by Eduard »

voxic11 wrote: post #30
jjgreen wrote: post #15

Earlier quoted context omitted.

key-value pairs where the = cannot be surrounded by spaces, so I have to write [Service] Type=oneshot WorkingDirectory={{ home }}/current/ Environment=RAILS_ENV=production ExecStart=/bin/sh -lc "bin/db-backup --verbose" which fills me with sadness

Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.

Standard INI format™:

https://specifications.freedesktop.org/desktop-entry/latest/...

Re: Love systemd timers

#178

Post by Eduard »

louiskottmann wrote: post #139

And you immediately lose the ability to do `crontab -l` on any server to know its scheduled tasks. Now you get to look around the myriad of places where you can put systemd files, and figure out which ones are base services and which ones are custom, with no general convention to go about it. Nope.

  /etc/crontab
  /etc/cron.d/*
  /etc/cron.hourly/*
  /etc/cron.daily/*
  /etc/cron.weekly/*
  /etc/cron.monthly/*
  /var/spool/cron/crontabs/*

Re: Love systemd timers

#179

Post by porridgeraisin »

I am not the greatest fan of most of systemd's features. I will always prefer it tho since I just view it as a "packaging format". The same way I view docker. It is just that it happens to be the format that a lot of software is using and I have almost no headache integrating services, timers, logging and such of software I install. Without systemd its a mighty pain. Everyone uses the same one thing and that makes me overlook any drawbacks of the model. Only if the entire system was set up by me and mostly ran my software and I was getting paid for it, I might not use systemd.

But one feature of systemd I will absolutely stand by is nspawn. It's just beautiful.

Re: Love systemd timers

#180

Post by Eduard »

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…

this issue?

https://github.com/systemd/systemd/issues/6680

Post reply on HN