3 ms·

who uses cron when you have systemd anyway?

by mangix 10y ago

adontz 10y ago
A lot of people who are familiar with cron already, but not with systemd. But, to be honest, writing crontab is easier task, systemd timers are not more intuitive than cron when you write them, i.e. I personally still look in documentation for various systemd options, but are IMHO much easier to read and more powerful, and have great "systemctl list-timers" view, but unfortunately not superset of crontab options. That's probably the second reason to still use crontab.
perlgeek 10y ago
Not everybody has systemd. The BSDs don't (iirc), and for example we are stuck with some Debian Wheezy host at $work, which don't come with systemd either. Also, lots of operators have decades of experience with cron, and don't want to give up on that easily. [Update] After reading https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.php/Systemd/Timers I see two more reasons * You don't have to write a service file to use cron jobs, which makes ad-hoc tasks much easier * Sending mails is the default for cron, which requires extra work with systemd.
int0x80 10y ago
So, obviously systemd has also taken over crontab? My god ... Really this is sick. I've to fight systemd to do some dead simple init.d custom services and it was awful. Even the process resource limits had to be setup in the sytemd config files. I like /etc/crontab. It is a simple text file. Nothing magic. Standard. Works every time. Well known by everybody. Works on a lot of UNIXes, old Linux systems etc. I don't want no new complexity and a new way to do things every 6 months. What I hate most is that all this is pushed through our throats no matter what we want. FFS. EDIT: BTW, I think luckily, /etc/crontab at least currently still works on Ubuntu Server 16.04 (what I've tried). I think this is the way to go. If you want to use some new features (systemd) you can opt-in. But don't break old stuff please.
- digler999 10y ago
  I swear within a year we're going to see a systemd written in ecma-6 asm.js using coffeescript running on node. Probably with some react-ive elements and no-sql to save configuration.
- klapinat0r 10y ago
  Care to give an example? What I'd call "dead simple init.d custom services" I find very easy to do in systemd, so I wonder if our definition is the same. Here's what I'd call a simple init.d-like example. non-needed things (if you think it's too complex) include: wait for fs mount and network, custom reload command, "don't log stdout" [Unit] After=network.target AssertPathIsMountPoint=/mnt/service-data-if-needed [Service] ExecStart=/some/binary Environment=CONF=/etc/i/guess.conf USER=nonrootmaybe ExecReload=/bin/pkill binary KillMode=process Restart=always StandardOutput=null [Install] WantedBy=multi-user.target EDIT: man 5 systemd.unit
  - int0x80 10y ago
    Well, to start a init.d service you only really need an executable and a few links to rc.X. Nothing more. I know about the lsb stuff and that but only gives a few warnings if you omit it. Still works as expected out of the box. For example, if your service daemonizes (forks) the systemd way wont work. You need fork=yes or something. For my likings is way more complex that it should be. The thing is we've gone from needing almost nothing 90% of the time (I just want my executable to be run when the system is up) to get the thing working to understanding a lot of sections, files, ill-named options etc.
    - klapinat0r 10y ago
      That's a fair point, but it sounds like we're moving into a debate on OSes switching to systemd by default. If we're comparing running a binary on startup vs. setting it up as a service in systemd, I wholeheartedly agree that you should always use the right tool for the job. So let's discuss the software, not the politics :) If we're talking about the original story (crontab) people should compare it to systemd timers if they're looking for alternatives - which I still prefer. I have no stake in OSes choice of default installed packages (be it init, openrc, or systemd), and agree with your parent comment that OSes shouldn't break (dropping crontab as an installed base package) without consideration. I haven't come across one of these OSes where it wasn't possible to install crontab from their default package managers, and in their main repositories, though.

who uses cron when you have systemd anyway?

by mangix 10y ago

who uses cron when you have systemd anyway?

A lot of people who are familiar with cron already, but not with systemd. But, to be honest, writing crontab is easier task, systemd timers are not more intuitive than cron when you write them, i.e. I personally still look in documentation for various systemd options, but are IMHO much easier to read and more powerful, and have great "systemctl list-timers" view, but unfortunately not superset of crontab options. That's probably the second reason to still use crontab.

perlgeek 10y ago

Not everybody has systemd. The BSDs don't (iirc), and for example we are stuck with some Debian Wheezy host at $work, which don't come with systemd either. Also, lots of operators have decades of experience with cron, and don't want to give up on that easily. [Update] After reading https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.php/Systemd/Timers I see two more reasons * You don't have to write a service file to use cron jobs, which makes ad-hoc tasks much easier * Sending mails is the default for cron, which requires extra work with systemd.

int0x80 10y ago

So, obviously systemd has also taken over crontab? My god ... Really this is sick. I've to fight systemd to do some dead simple init.d custom services and it was awful. Even the process resource limits had to be setup in the sytemd config files. I like /etc/crontab. It is a simple text file. Nothing magic. Standard. Works every time. Well known by everybody. Works on a lot of UNIXes, old Linux systems etc. I don't want no new complexity and a new way to do things every 6 months. What I hate most is that all this is pushed through our throats no matter what we want. FFS. EDIT: BTW, I think luckily, /etc/crontab at least currently still works on Ubuntu Server 16.04 (what I've tried). I think this is the way to go. If you want to use some new features (systemd) you can opt-in. But don't break old stuff please.

digler999 10y ago
I swear within a year we're going to see a systemd written in ecma-6 asm.js using coffeescript running on node. Probably with some react-ive elements and no-sql to save configuration.
klapinat0r 10y ago
Care to give an example? What I'd call "dead simple init.d custom services" I find very easy to do in systemd, so I wonder if our definition is the same. Here's what I'd call a simple init.d-like example. non-needed things (if you think it's too complex) include: wait for fs mount and network, custom reload command, "don't log stdout" [Unit] After=network.target AssertPathIsMountPoint=/mnt/service-data-if-needed [Service] ExecStart=/some/binary Environment=CONF=/etc/i/guess.conf USER=nonrootmaybe ExecReload=/bin/pkill binary KillMode=process Restart=always StandardOutput=null [Install] WantedBy=multi-user.target EDIT: man 5 systemd.unit
- int0x80 10y ago
  Well, to start a init.d service you only really need an executable and a few links to rc.X. Nothing more. I know about the lsb stuff and that but only gives a few warnings if you omit it. Still works as expected out of the box. For example, if your service daemonizes (forks) the systemd way wont work. You need fork=yes or something. For my likings is way more complex that it should be. The thing is we've gone from needing almost nothing 90% of the time (I just want my executable to be run when the system is up) to get the thing working to understanding a lot of sections, files, ill-named options etc.
  - klapinat0r 10y ago
    That's a fair point, but it sounds like we're moving into a debate on OSes switching to systemd by default. If we're comparing running a binary on startup vs. setting it up as a service in systemd, I wholeheartedly agree that you should always use the right tool for the job. So let's discuss the software, not the politics :) If we're talking about the original story (crontab) people should compare it to systemd timers if they're looking for alternatives - which I still prefer. I have no stake in OSes choice of default installed packages (be it init, openrc, or systemd), and agree with your parent comment that OSes shouldn't break (dropping crontab as an installed base package) without consideration. I haven't come across one of these OSes where it wasn't possible to install crontab from their default package managers, and in their main repositories, though.