Hacker News Reader

Comment by int0x80 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

> 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.

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.

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.

Reply on news.ycombinator.com