6 ms·
Better use systemd as a reliable cron replacement https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.php/Systemd/Timers
by betaby 7y ago
Better use systemd as a reliable cron replacement https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.php/Systemd/Timers
- fractalf 7y agoAnd exacly why is that better than cron?
- zelly 7y agobecause it is Deprecated™
- crappy-doo 7y agocron just needs to run until i retire... then you guys can fail using whatever new tools are cool for you this week...
- trulyrandom 7y agoBecause it integrates nicely with the rest of systemd. If you use systemd, there's no real reason to also have a crond running.
- hartator 7y agoexcept systemd will be replaced by something else soon whereas cron has been around for a while.
- danellis 7y agoWhat is systemd being replaced by?
- hartator 7y agosystemd vs initd vs upstart. I am pretty sure systemd will be gone soon too as well. Syntax is harder than upstart for example.
- gtirloni 7y agoI'm sorry, that ship has sailed. systemd is more than just a init system at this point. Anyway, I'm also curious about what is replacing it soon.
- FillardMillmore 7y agoI think both have their use cases. For quick and dirty things (like manual logging/system performance), cron works just fine and is quicker to set up. For tasks that require dependencies or have to happen at very specific points in time (like immediately after the network services are started), systemd is more suited to the task. There are of course quite a few people who dislike systemd for justifiable reasons (but I doubt it receives the disdain that SELinux does), here's a starting point: https://ihatesystemd.com/ https://ihatesystemd.com/ That said, I very much like systemd and I hope it isn't going anywhere. I think it's improved on a lot of things from the SysVinit days and I hope and believe that its shortcomings will be addressed and improved in the future.
- theamk 7y agoMy problem with cron for short tasks is that pretty often I forget to add logging and/or locking. And then machine runs out of resources because of all the parallel jobs, and there aren’t even any logs.
- zaphirplane 7y agoI so much more prefer people to respond with reasons than say you should use abc, why, because it’s better
- arcticfox 7y agoI've also used crontab.guru a million times, precisely 0 for crond itself. Tons of systems use the same syntax. So the super dismissive "systemd is better" response is kind of missing the point anyways, even with any type of legitimate justification.
- betaby 7y agoRestarts, dependencies, various resource limits, etc.
- cripblip 7y agoDefine a unit and run it individually to troubleshoot vs modifying the crontab for 1 min ahead Logging in journalctl Built in jitter options to spread tasks across a window in a large fleet Ability to use the unit as a dep for other things Instrumented in systemctl list-timers Store config in user home dir (I think ) for tasks owned by a user
- simcop2387 7y agoAlso the ability to easily keep the task from running multiple copies at once.
- gorgoiler 7y agoThese aren’t really better, they are just different ways of doing things the old fashioned way. (e.g. put all your logic in one script, test it with “env -“, lock exclusively with flock if you need it, or whatever else you have to hand in your language of choice.)
- cripblip 7y ago:shrug:, yeah the old fashioned way is possible too (I have to support both), systemd just gives a consistent pattern to make common tasks easy.
- emmelaich 7y agoBecause `systemctl list-timers` is a nicer output than `crontab -l -u <user>`
- profmonocle 7y agoA nice feature of Systemd timers is the ability to say something like "run once per 24 hour period, but I don't care when". The task runs at a random time during the period, which is nice for tasks that hit network services, since you don't get a zillion clients hitting the server at the same time. (i.e. local midnight or UTC midnight.) Package repo updates and Let's Encrypt renewals are a couple services I've seen use this. There isn't a great way to do this with cron that I know of, besides running some script that sleeps for a random duration. That said, I still use cron for things that don't need this feature because it's portable and I'm just more familiar with it.
- tyingq 7y agoThere is an "on boot" parameter which may be handy for things that should run both periodically, and at system start. Narrow use case, but it happens.
- jjjbokma 7y agoSome cron implementations do have @reboot (and several others).
- hartator 7y ago> Description=Run foo weekly and on boot I hate this kind of syntax.
- arminiusreturns 7y agoOne more thing systemd tries to take over. Do not want. Instead, try GNU mcron (guile-based). "The mcron program represents a complete re-think of the cron concept originally found in the Berkeley and AT&T unices, and subsequently rationalized by Paul Vixie. The original idea was to have a daemon that wakes up every minute, scans a set of files under a special directory, and determines from those files if any shell commands should be executed in this minute. The new idea is to read the required command instructions, work out which command needs to be executed next, and then sleep until the inferred time has arrived. On waking the commands are run, and the time of the next command is computed. Furthermore, the specifications are written in scheme, allowing at the same time simple command execution instructions and very much more flexible ones to be composed than the original Vixie format. This has several useful advantages over the original idea. (Changes to user crontabs are signalled directly to mcron by the crontab program; cron must still scan the /etc/crontab file once every minute, although use of this file is highly discouraged and this behaviour can be turned off). " https://www.gnu.org/software/mcron/manual/mcron.html#Introduction https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...
- michaelmrose 7y agoI love the idea and like lisp but the lisp syntax seems worse than both cron syntax and natural English. Given the narrowness of the domain is there a good reason not to use English?
- arminiusreturns 7y agoYou'd have to ask the devs, but I think lispy people tend to live in a bit of a lisp bubble. I know I sorta do with elisp because of emacs.
- jordanthoms 7y agoThe cron syntax is used by a bunch of other things as well, e.g k8s cronjobs so sites like this are still useful even if you aren't using a traditional cron
- 77pt77 7y agoHas anyone ever managed to have per user systemd services? For whatever reason it never works for me, including timers.
- stevekemp 7y agoYup. You need to enable the "linger" stuff, so that jobs work when the user isn't around. But I deploy a lot of services running as specific users and it works well. Good overview here: https://wiki.archlinux.org/index.php/systemd/User https://wiki.archlinux.org/index.php/systemd/User (You can install global services, and add `user=x`, etc, obviously. But I like to keep things self-contained.)
- cripblip 7y agoThe target names for install are confusingly different (default vs multi-user) , check that when enabling, works really well
- chousuke 7y agoI suspect that if someone just replaced crond with a thing that generates systemd timers, few people would notice.
- pnako 7y agoIt's only supported on Lennax though. If you use *BSD, Jenkins, and everything else you use the standard cron syntax.
- tannhaeuser 7y ago> Lennax I'm so going to steal this giving gold
- alxlaz 7y agoNot that I have a problem with systemd, which I don't hate and I use extensively (both in my customers' products and on my machine because it's the default init system of the distro I use), but this thread illustrates a lot of why a lot of pre-systemd Linux users just don't dig it. Every time someone asks "why should I use systemd instead of cron" they get these (technically correct -- the best kind of correct!) answers about how systemd timers allow you to attach jobs to cgroups, define dependencies, test unit files separately vs. changing crontabs for 1 minute ahead (which I don't think is a "cron idiom" -- I've certainly never done i -- but we all have our weird hacks), and how it has built-in jitter options and per-job environment settings and whatnot. These are all very relevant for real-life workloads of super advanced cloud systems, I'm sure. (Which I'm not saying in a derogatory way. I haven't written back-end code in like 12 years now, the things that are happening there today blow my mind. I know these are complex systems so I'm pretty sure they have complex problems which have complex solutions.) But guys, I just need to run a bash script every day at 2 AM. 99% of us just need to run a bash script every day at 2 AM. This has worked reliably in cron since practically forever. I have grumpily learned the new way of doing it but I can't really justify the time I've put into it, nor the (very extensive) troubleshooting that was involved in it. I just woke up one morning and sat down in front of a Linux machine and I found out that there's a new way to run things at 2 AM. If you want to woo me with cool systemd-timers features, tell me that it finally has an equivalent to cron's MAILTO, so that I don't have to write yet another systemd unit file that wraps a script written by me if I want to get a notification when a job has failed, because somehow that hasn't made its way into the "everything but the kitchen sink" list which otherwise includes things like attaching jobs to cgroups.
- yrro 7y agoI suppose it would be quite nice to have a MailTo= directive in a service. When the service stops, systemd could retrieve whatever it logged to the journal and mail it to the specified address. Until such a feature is implemented, you could try: ExecStart=/bin/bash -c 'shopt -o pipefail; mycommand | mail -s foo@example.com' Certainly not as convenient as MailTo=, but a lot less complicated than using OnFailure= with a separate service that tries to mail you the output.