3 ms·

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 f

by 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.
- int0x80 10y ago
  Yep, I was complaining a bit of the move to systemd. To run a binary (that acts as a daemon in the end) with no especial handling needed by the OS and nothing fancy (just run at runlevel 3, I don't even need a "clean" shutdown, everything is handled by the process) I couldn't find a simple way to do it without systemd. The /etc/init.d/ directory was under control (!!) by systemd. The binary wouldn't even run manually, systemd intercepted the process running from that directory. So I had to write a systemd service file. Not a big deal after all, but I didn't like it. About the timers in systemd I haven't even look at them. As long as I don't need them I'm fine with 'cron' and 'at'. Maybe they are not the best posible systems, but IMO work quite well (and I don't have to change my code to use them). If at some point I encounter problems or limitations with my uses of cron and those are fixed by systemd I will happily update to systemd timers. For now the work perfectly fine for my needs.

by int0x80 10y ago

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.

int0x80 10y ago
Yep, I was complaining a bit of the move to systemd. To run a binary (that acts as a daemon in the end) with no especial handling needed by the OS and nothing fancy (just run at runlevel 3, I don't even need a "clean" shutdown, everything is handled by the process) I couldn't find a simple way to do it without systemd. The /etc/init.d/ directory was under control (!!) by systemd. The binary wouldn't even run manually, systemd intercepted the process running from that directory. So I had to write a systemd service file. Not a big deal after all, but I didn't like it. About the timers in systemd I haven't even look at them. As long as I don't need them I'm fine with 'cron' and 'at'. Maybe they are not the best posible systems, but IMO work quite well (and I don't have to change my code to use them). If at some point I encounter problems or limitations with my uses of cron and those are fixed by systemd I will happily update to systemd timers. For now the work perfectly fine for my needs.