4 ms·

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'

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.
  - 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.
dingaling 10y ago
> After=network.target That only guarantees that your network devices have been enumerated, not that they are available with assigned addresses. I encountered this problem with SSH failing to start on Ubuntu 16.04 server. systemd was launching SSH before the binding address had been assigned, causing SSH to abort and fail and the server to continue to boot without any way of accessing it remotely. Workaround ( at the physical console ) was to add a Retry to the SSH unit and time it to coincide with the address having been assigned[0]. hacky, but no other unit imperatives worked. [0] Default behaviour in the SSH unit, at least on Ubuntu, is that it tries once and never again.
- digi_owl 10y ago
  And here i thought systemd was about getting rid of those waits. Also, i expect the faithful to come and claim it is a Canonical fuckup.

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.

dingaling 10y ago

> After=network.target That only guarantees that your network devices have been enumerated, not that they are available with assigned addresses. I encountered this problem with SSH failing to start on Ubuntu 16.04 server. systemd was launching SSH before the binding address had been assigned, causing SSH to abort and fail and the server to continue to boot without any way of accessing it remotely. Workaround ( at the physical console ) was to add a Retry to the SSH unit and time it to coincide with the address having been assigned[0]. hacky, but no other unit imperatives worked. [0] Default behaviour in the SSH unit, at least on Ubuntu, is that it tries once and never again.

digi_owl 10y ago
And here i thought systemd was about getting rid of those waits. Also, i expect the faithful to come and claim it is a Canonical fuckup.