Live data from Hacker News

Love systemd timers

blog.tjll.net

151–160 of 309 posts

Re: Love systemd timers

#151

I have a Canon printer, I actually can't trust that their print nozzle won't get jammed up after sitting idle for a while. So I had claude setup a systemd script to print a picture of my dog every week, I ensure it has enough CMYK spectrum to stress the printer. Its a nice surprise every monday as I sit on my desk to see a sudden picture pop up from the printer :)

Laser printers are your friend. The savings on consumables alone will make it pay for itself.

Laser printers are great for documents, but not very good for photos.

I have an ink jet printer that I like. I don't print very often (average a couple pages per week) but when I do it's a mix of documents and photos. The ink isn't cheap, but the quality seems good and for the amount I print the expense is minor.

Re: Love systemd timers

#152
post #92

Earlier quoted context omitted.

How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.

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

If you know the syntax, it's still actually rather trivial. Still easier to read than advanced cron magic.

Re: Love systemd timers

#154

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 PR or when it comes to being even near feature parity with what they tried to replace. But now, they aren't just at feature parity, they surpassed plain old cron.

Maybe it is time to lay cron to rest, at least slowly.

Re: Love systemd timers

#155
post #152

Earlier quoted context omitted.

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

If you know the syntax, it's still actually rather trivial. Still easier to read than advanced cron magic.

> 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.

Re: Love systemd timers

#156
post #69

Earlier quoted context omitted.

Could have been worse. Could have been YAML. Could have been XML.

XML - I see you’ve used macOS’ LaunchD, the system that inspired Systemd

Yeah, I'm a man of culture like this. However, systemd with its service dependencies runs circles around launchd in pretty much every aspect.

Re: Love systemd timers

#157
post #32

Earlier quoted context omitted.

What? You absolutely can have spaces; most of mine look more like [Service] Type = oneshot WorkingDirectory = %h/current/ Environment = RAILS_ENV=production ExecStart = /bin/sh -lc "bin/db-backup --verbose"

Friend, you have changed my life

My epiphany a month ago was that I can use

   Environment = MULTIPLE=environment VARIABLES="in single line"

Re: Love systemd timers

#158
post #140
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.

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.

Re: Love systemd timers

#159
post #127
post #79

Earlier quoted context omitted.

"You just put numbers aligned with the titles." That is not a fair summarization of their point because that is not the grammar. There's commas, slashes, asterisks, combinations, and then if you want randomization you need to put it in the command itself because cron can't do it. (Some crons can, but it's not a general capability of cron.) Writing a non-trivial cron spec is not easy.

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…

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

Re: Love systemd timers

#160
post #116
post #92

Earlier quoted context omitted.

How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.

$ 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

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.

Post reply on HN