4 ms·
And exacly why is that better than cron?
by fractalf 7y ago
And 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).