Hacker News Reader

Comment by xarope | Hacker News Reader

I've not looked closely at systemd yet, but my initial attempts with using sysctl on a test ubuntu 16.04 server, seems to reflect my experience with usage of svcadm in solaris/illumos, where the latter requires XML manifest instead of a "simple" script.

Is this an apt comparison for systemd, or is it way better/worse (I'm not an expert, so I'll leave the qualitative opinions to others!) than that?

View on HN

Well, in most (older) init systems, boot scripts were shell scripts and you could do anything if you knew how, including shooting yourself in the foot. Great flexibility, great responsibility.

In systemd, services are described in a simple file with a few keywords, and systemd tries to do all the magic itself, in a way replacing the scripting part and all the possible code paths that could be gotten that way.

So if something in the system's boot or a process' start-up procedure doesn't work now, it's systemd's fault and not yours or whoever wrote the shell scripts in other init systems; and if the simple configuration file is not complex enough to do something you could do easily with a shell script, than it's also systemd's fault for being too simple.

I'm an old-timer and I like shell scripting, but also think systemd makes writing service files easier and has benefits such as built-in support for cgroups, security features (user/group, chroot, ...) and mini-services like basic ntp server. There were some bugs when distributions started to include it by default some years back, but I haven't had any problems lately.

One of the problems with systemd seems to be that it makes init scripts look simpler by spreading their complexity across multiple files all over the filesystem instead. The unit file systemd proponents were showing off as an example a few years back certainly looked simple compared to the init script it replaced... until you realise that its functionality had actually been split across several unit files and a bunch of shell scripts that they called. Look at this article and just count number of moving parts involved in getting NFS working with systemd too. Multiple service, target and socket unit files with the same name but subtly different behaviour, multi-hundred-line shell scripts in a directory most people won't even realise exists modifying some of them at runtime, ... In non-systemd init systems that'd all probably be one init script, and the fact that it was all in one place would sure make it look more complex.

> In systemd, services are described in a simple file with a few keywords, and systemd tries to do all the magic itself

So rather than building the necessary complexity out of simple, understandable instructions which can be presented on-screen in full, it hides its complexity under a very few complex, frequently badly-named instructions which are certain to be poorly documented even for Linux's standards.

Sign me up! I'll be unfirable!

units are simple ini-like files. Unless you want some very specific behaviour (and if you're the app's author, you know if you do), your service file will be normally as simple as:

    [Unit]
    Description=Some description

    [Service]
    Type=simple
    ExecStart=/the/service/binary

    [Install]
    WantedBy=multi-user.target

The rest is stuff on top (user/group, namespaces, cgroups, stdout redirection, socket activation, ordering, etc.) Actually running the services instead of forking them also allows you to get rid of lots of silly pidfile handling options.

> simple

This might look simple, because "Hello world" is simple in most languages. But if you really work with them, you will encounter many hidden complexities.

I've written a few daemons now, and the files haven't been a lot more complicated, and the extensions have been obvious (I need to give this process some capabilities, ok set CAPABILITY_BOUNDING_SET).

Systemd being responsible for daemonising also removes several corner cases I could screw up on daemon implementation and saved me time.

All in all I had a much easier experience that I did with similar tasks on SysV.

No, I meant it. I wrote the service files for a number of services and they usually come down to exactly this. Sometimes they require more attention if you want to get more out of systemd. For example socket activation requires proper handling in the app's source code. And if you want to use cgroups, you have to know how they work.

But in practice, the description of all of that is still simple. Have a look at your service descriptions in /usr/lib/systemd/system - there will be a few services with crazy dbus activation and a long list of options, but most of the others are quite simple and the extra options are only to make it work better, not to make it work in general.

And being able to simply set things like NoNewPrivileges, MemoryDenyWriteExecute, and Protect* without going into LSM profiles is a great simplification.

Okay, then maybe the complexity doesn't come from the .service/.socket files but from the used mechanisms.

A colleague of mine had the problem that one of his applications was shut down because the user context which this service belonged to, logged out/disconnected (I think it was a system user). So he had to hack something together to ensure that the service is not affected by this.

Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.

And then logout and login again, and have 200 sessions of shitty daemons like megasync or dropbox in your process manager.

No thanks.

Individual daemons can be tuned with systemd-run/loginctl linger - but I guess posting snarky comments on HN is way more constructive than RTFM.

Yes, exactly. That’s how it’s supposed to be: Everything is killed by default, and you have to elevate it with systemd-run to make it work properly.

Allowing any process to linger around by default is just stupid, which is why "Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf." is as horrible advice as "just add your own user to the root group".

In other words, systemd has reinvented nohup and crew...

Except, this time with a working permission system, and proper limits per user.

That’s something no other competitor has provided before.

So what you're referring to is that he had some unit started within some user's scope and then killed the scope which promptly stopped his unit. This behavior was actually not the default on most distros until not too terribly long ago. Basically, the way this used to work was that on logout, all of the user's processes would get signaled that they need to close but it was up to the application to handle how to respond to that signal. Sometimes daemons would misbehave and there's nothing to differentiate "this app is supposed to end but hasn't" and "this app is choosing to ignore the signal because it needs to stay running". With systemd, there is an option to reap these processes so that when you log out, you never have to worry about some misbehaving process hanging around and causing problems when you log back in.

The way to fix this without disabling the feature is by explicitly putting the process in it's own scope. That doesn't take special permissions to do, it's just that it needs to be done explicitly instead of just ignoring SIGHUP.

Your colleague could always push for systemd to be fixed. The world knows the program and the function to fix.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

I may be reading it wrong, but it seems to me that Pitt it more interested in doubling down on the new default.

https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...

I've written a few unit files, including some edge cases like binding one service to another, and it's just a few more key/value pairs.

This being said, upstart has a similarly simple setup. Any time I have to fiddle with sysv init files, I long for either of upstart or systemd.

Units are not simple. I spent several hours to find out the proper combination of arcanes to run uwsgi and systemd. Same with gunicorn.

Turns out you need to figure out After, KillSignal, pidfile, and some options in uwsgi configuration itself. Oh, and "Type=simple" doesn't work, you need forking.

And this is poorly documented, it's hard to find materials en the web to help you and you are reduced to make many trial and errors with systemd itself giving you few clues of what's going wrong.

It's, however, easier that bash scripts, so it's an improvement.

Seconded. I had to do trial and error several times to understand why systemd didn't start the programs I could start with the same arguments on the command line.

The documentation is not that bad but declaring with configuration what you programmed with a script has some limits. Basically you have to learn another language on the top of the scripting one that you still have to use in other parts of the system.

Nevertheless I found that past that point it's easier to read a short configuration file than a long init script. I didn't run in big problems so far, but that systemctl reenable is wierd. Why can't it figure it out by itself?

> Oh, and "Type=simple" doesn't work, you need forking.

Why would you not use type=simple?

I don't know. I just know If I do, wsgi doesn't start.

It is extremely well documented in `man systemd.service` and `man systemd.unit`. Read the option descriptions in the section pertaining to what you want to do of each, look at the examples, and you should be good to go.

Anytime somebody mention a man file as "good documentation", I feel the same as somebody pointing assembly code as "easy to understand". The simple medium make it not "easy". Yes, it's great to have a good man file if you have nothing else, just like it's nice to have a wooden wheel if you don't have a rubber tire, but come on.

Did I say it was good documentation because it was in a simple format? No. It’s good documentation because it’s thorough, well-organized, and comes with lots of examples. That it’s a man page has nothing to do with it (except for the convenience of getting `man systemd.<tab>` autocomplete).

Actually, it's fairly mediocre doco; and manual pages are reference doco, not tutorials or user guides.

That said, two of us have already pointed out in this discussion where other doco exists for the subject at hand, outwith reference manual pages.

If you get rid of all the shite people like to stuff in them, even sysv-style init scripts can be short and readable.

As seen over at BSD...

> Turns out you need to figure out After, KillSignal, pidfile, and some options in uwsgi configuration itself. Oh, and "Type=simple" doesn't work, you need forking.

You could have also just copy/pasted the examples from the uwsgi documentation.

http://uwsgi-docs.readthedocs.io/en/latest/Systemd.html

Forking is wrong, and there most definitely are materials on the WWW about this.

* http://unix.stackexchange.com/a/242860/5132

Both uwsgi and gunicorn can run with type simple. Actually it's easier if they do, because you don't need pidfiles anymore. But this is not systemd specific. You need to understand the difference in behaviour, regardless which init you're using. In sysv using the wrong type basically means you're blocking the startup.

Not understanding how the daemon forking works is not the same as systemd being complicated.

Having to understand the whole system just to start a command is being complicated.

How do you imagine it working otherwise? You have to understand the difference between forking and simple type even if you start commands in your shell. Otherwise you'll end up saying "this command doesn't even work, I run it and nothing happens". This is basic knowledge. It's a "you must be this tall to run services on Linux" benchmark.

Hmm, I found the systemd scripts (plain text files) very readable and decently simple.

As a script, "start the service" is extremely readable and simple on the surface.

Exactly what I'd need to do to be able to put a #! on the line before is slightly more complex and you won't be able to reason about it yourself except by guesswork but that's alright because I've got it right. You can trust me.

I've not looked closely at systemd yet, but my initial attempts with using sysctl

sysctl has nothing to do with systemd though.

> sysctl has nothing to do with systemd.

For now... /s

systemd-sysctl exists already. (Okay, but its not a replacement for it)

I use systemd to manage the (sort-of) microservices for some web app projects I've done. To me, the unit files are simple and even beautiful compared to the big pain that init scripts used to be.

Those old init scripts weren't simple - to do anything useful you had to copy and paste a whole heap of sh boilerplate...

No offense, but this comment only indicated that a syntax is simpler and has nothing to do with the actual quality and stability of systemd.

This is my regular problem in systemd arguments. I understand learning init script - and bash as a consequence - can be tiring, but judging a software by how easy or not is it to configure is utterly and fundamentally wrong.

After a certain point, systemd is not easier to configure than any earlier system; nor is it any more stable, or, god forbid, easier to replace a part of it.

Please stop glorifying things that you're only touched the surfaces of.

It's something that's been reliably working for me over many servers over the last two or three years...

I don't care if it's easy to replace bits of - the people who produce the distribution I use can worry about that. All I care about is that it has worked really well for me in production and I have found it much easier to use and maintain than older systems.

Copy/paste was the real problem, not init scripts. Look at the init scripts of FreeBSD some time. They're short, well-documented, and built around reusable components. SysV init was a mess because init scripts became a cargo cult of copy-paste, rather than actually using all the capabilities that were available.

Well it pretty much started out as a Linux clone of SMF, but has grown to encompass pretty much anything not covered by the kernel, GNU userland, and the desktops...

Patience young padawan.

Reply on news.ycombinator.com