7 ms·

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 sv

by xarope 10y ago

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?

izacus 10y ago
Hmm, I found the systemd scripts (plain text files) very readable and decently simple.
- ChoHag 10y ago
  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.
viraptor 10y ago
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.
- chme 10y ago
  > 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.
  - rkangel 10y ago
    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.
  - viraptor 10y ago
    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.
    - chme 10y ago
      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.
      - ZZBop 10y ago
        Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.
        kuschku 10y ago
- sametmax 10y ago
  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.
  - pmontra 10y ago
    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?
  - samtoday 10y ago
    > Oh, and "Type=simple" doesn't work, you need forking. Why would you not use type=simple?
    - sametmax 10y ago
      I don't know. I just know If I do, wsgi doesn't start.
  - minitech 10y ago
    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.
    - 10y ago
tremon 10y ago
I've not looked closely at systemd yet, but my initial attempts with using sysctl sysctl has nothing to do with systemd though.
- chme 10y ago
  > sysctl has nothing to do with systemd. For now... /s systemd-sysctl exists already. (Okay, but its not a replacement for it)
digi_owl 10y ago
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...
- ChoHag 10y ago
  Patience young padawan.
wvh 10y ago
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.
- makomk 10y ago
  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.
- ChoHag 10y ago
  > 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!
stephen_g 10y ago
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...
- pmlnr 10y ago
  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.
  - stephen_g 10y ago
    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.
- Sanddancer 10y ago
  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.

by xarope 10y ago

izacus 10y ago

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

ChoHag 10y ago
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.

viraptor 10y ago

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.

chme 10y ago
> 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.
- rkangel 10y ago
  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.
- viraptor 10y ago
  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.
  - chme 10y ago
    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.
    - ZZBop 10y ago
      Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.
      - kuschku 10y ago
sametmax 10y ago
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.
- pmontra 10y ago
  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?
- samtoday 10y ago
  > Oh, and "Type=simple" doesn't work, you need forking. Why would you not use type=simple?
  - sametmax 10y ago
    I don't know. I just know If I do, wsgi doesn't start.
- minitech 10y ago
  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.
  - 10y ago

tremon 10y ago

I've not looked closely at systemd yet, but my initial attempts with using sysctl sysctl has nothing to do with systemd though.

chme 10y ago
> sysctl has nothing to do with systemd. For now... /s systemd-sysctl exists already. (Okay, but its not a replacement for it)

digi_owl 10y ago

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

ChoHag 10y ago
Patience young padawan.

wvh 10y ago

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.

makomk 10y ago
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.
ChoHag 10y ago
> 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!

stephen_g 10y ago

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

pmlnr 10y ago
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.
- stephen_g 10y ago
  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.
Sanddancer 10y ago
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.