5 ms·

The systemd fallacy

32 points by uggedal 15y ago

count 15y ago
Switching from shell to C is a problem from DoD users - you aren't allowed to have a compiler installed on a production machine, so to edit your init process (I guess they aren't scripts anymore!), you'd have to have a separate machine to do the compiling.
- zb 15y ago
  Systemd services are configured with a .service file, which is a text file (but not a shell script). I don't know why the author made the bizarre suggestion that anybody would start tinkering with the source of systemd itself in order to configure services, and it would be impolite to speculate. Suffice to say that nobody does this. Certainly you can take advantage of more systemd features by modifying the source of the service to explicitly support them; however, this is not something users/sysadmins should ever need to do themselves.
- rwmj 15y ago
  This isn't how it works -- you can use shell scripts within systemd, it's just that the so-called standard init scripts have been replaced. Note that old-style SysV init scripts weren't really editable in most cases. They were supposed to stick to a rigid set of standards (which they often didn't, causing lots of bugs), and edits made to them might be silently reverted during an upgrade. For this reason, most distros recommend /etc/sysconfig/* files for persistent configuration of init scripts, which systemd also uses (or editing the textual foo.service file).
  - count 15y ago
    Interesting, thanks.
- 4ad 15y ago
  Not installing compilers on production machines is a relic from 1990 that doesn't impact security in any meaningful way. If I have access to your machine I can upload a compiler and/or I can upload binaries generated by a compiler at my end of the pipe.
  - binarycrusader 15y ago
    Relic or not, that's the way things are in many businesses and governments.
  - Someone 15y ago
    I think systems that do not have a compiler will try hard to make it impossible for normal users to do chmod +x, too. Users likely will not have a login shell, and they will have a umask set to prevent creation of executable files.
  - alexchamberlain 15y ago
    Is it not more that compiling on a different machine should force you to test on that machine, thus uploading a known good binary to production?
ootachi 15y ago
I can't take this rant seriously when it dismisses the importance of fast startup. "You shouldn't care if your system starts up slowly" is just untenable.
- count 15y ago
  The multi-second difference in software start time, after waiting 5+ minutes for my RAID to initialize and all the onboard crap to check out is really negligible.
  - switch007 15y ago
    Yes. This is perhaps the point (s)he meant to make. There are other processes that take much longer, and the tens of seconds difference in the boot process isn't that great in the grand scheme of things.
  - binarycrusader 15y ago
    Except if you're using ksplice on Linux to start a new kernel, you won't be waiting for RAID to initialise, which means those seconds do matter. (Or fast reboot on Solaris.) In many SLAs, the amount of time the system is unavailable can count against the company providing the server. Minimising the amount of downtime is a win for everyone.
    - count 15y ago
      If you're basing downtime avoidance on 'how fast I can boot', you're doing it wrong.
      - binarycrusader 15y ago
        Stop and think about this for a moment. Given the number of potential updates that may require a reboot to a system that is regularly maintained (for security and/or other reasons) shaving seconds off the boot process can really add up. The number of seconds that a system isn't available to serve requests can mean the difference between six nines and three nines of availability easily over the course of a year. It has nothing to do with "how fast I can boot", it's strictly about the amount of time the system is available to perform its expected operations. No one cares if you can't serve requests because it was rebooting or some other reason, the availability of the system's desired functionality is all that counts.
rwmj 15y ago
It really matters for servers how long they take to boot, particularly when you look at virtual machines / clouds, where they are thrown up and torn down rapidly.
s_tec 15y ago
It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page. A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this: [Unit] Description=My Daemon [Service] ExecStart=/usr/bin/mydaemon --some --flags So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.
- mst 15y ago
  "It's obvious that the author of this article has never actually used systemd." There's no need to start your article by being a douchebag. You could just make your point. Also, I don't think you really got it right here. His point is that lots of functionality has moved from shell scripts to C. Yes, you have an ini-style configuration file. That's not the same as a shell script. postfix took the simple-flat-config-file model whereas exim provides a much richer language. Some years ago I attempted to do something slightly odd for SQL auth in both, and found that postfix only let me use SASL, and SASL didn't have a driver for what I wanted, and therefore in order to make it do what I wanted I needed to write a C-based SASL driver to execute the SQL I wanted. In exim it was 3 or 4 lines of config. Similarly, if I hit something systemd can't do I now have to write C to add a config file, rather than write a couple of lines of shell. that is what the author means. I could certainly see an advantage to providing an ini-based approach as well for people who regard current LSB conmpliant init scripts as "shell scripts that made no sense to me" - and for people like me who -do- love them, but would be quite happy with a simple way to configure simple things. But please don't try and take that power away from me when I need it.

32 points by uggedal 15y ago

count 15y ago

Switching from shell to C is a problem from DoD users - you aren't allowed to have a compiler installed on a production machine, so to edit your init process (I guess they aren't scripts anymore!), you'd have to have a separate machine to do the compiling.

zb 15y ago
Systemd services are configured with a .service file, which is a text file (but not a shell script). I don't know why the author made the bizarre suggestion that anybody would start tinkering with the source of systemd itself in order to configure services, and it would be impolite to speculate. Suffice to say that nobody does this. Certainly you can take advantage of more systemd features by modifying the source of the service to explicitly support them; however, this is not something users/sysadmins should ever need to do themselves.
rwmj 15y ago
This isn't how it works -- you can use shell scripts within systemd, it's just that the so-called standard init scripts have been replaced. Note that old-style SysV init scripts weren't really editable in most cases. They were supposed to stick to a rigid set of standards (which they often didn't, causing lots of bugs), and edits made to them might be silently reverted during an upgrade. For this reason, most distros recommend /etc/sysconfig/* files for persistent configuration of init scripts, which systemd also uses (or editing the textual foo.service file).
- count 15y ago
  Interesting, thanks.
4ad 15y ago
Not installing compilers on production machines is a relic from 1990 that doesn't impact security in any meaningful way. If I have access to your machine I can upload a compiler and/or I can upload binaries generated by a compiler at my end of the pipe.
- binarycrusader 15y ago
  Relic or not, that's the way things are in many businesses and governments.
- Someone 15y ago
  I think systems that do not have a compiler will try hard to make it impossible for normal users to do chmod +x, too. Users likely will not have a login shell, and they will have a umask set to prevent creation of executable files.
- alexchamberlain 15y ago
  Is it not more that compiling on a different machine should force you to test on that machine, thus uploading a known good binary to production?

ootachi 15y ago

I can't take this rant seriously when it dismisses the importance of fast startup. "You shouldn't care if your system starts up slowly" is just untenable.

count 15y ago
The multi-second difference in software start time, after waiting 5+ minutes for my RAID to initialize and all the onboard crap to check out is really negligible.
- switch007 15y ago
  Yes. This is perhaps the point (s)he meant to make. There are other processes that take much longer, and the tens of seconds difference in the boot process isn't that great in the grand scheme of things.
- binarycrusader 15y ago
  Except if you're using ksplice on Linux to start a new kernel, you won't be waiting for RAID to initialise, which means those seconds do matter. (Or fast reboot on Solaris.) In many SLAs, the amount of time the system is unavailable can count against the company providing the server. Minimising the amount of downtime is a win for everyone.
  - count 15y ago
    If you're basing downtime avoidance on 'how fast I can boot', you're doing it wrong.
    - binarycrusader 15y ago
      Stop and think about this for a moment. Given the number of potential updates that may require a reboot to a system that is regularly maintained (for security and/or other reasons) shaving seconds off the boot process can really add up. The number of seconds that a system isn't available to serve requests can mean the difference between six nines and three nines of availability easily over the course of a year. It has nothing to do with "how fast I can boot", it's strictly about the amount of time the system is available to perform its expected operations. No one cares if you can't serve requests because it was rebooting or some other reason, the availability of the system's desired functionality is all that counts.

rwmj 15y ago

It really matters for servers how long they take to boot, particularly when you look at virtual machines / clouds, where they are thrown up and torn down rapidly.

s_tec 15y ago

It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page. A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this: [Unit] Description=My Daemon [Service] ExecStart=/usr/bin/mydaemon --some --flags So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.

mst 15y ago
"It's obvious that the author of this article has never actually used systemd." There's no need to start your article by being a douchebag. You could just make your point. Also, I don't think you really got it right here. His point is that lots of functionality has moved from shell scripts to C. Yes, you have an ini-style configuration file. That's not the same as a shell script. postfix took the simple-flat-config-file model whereas exim provides a much richer language. Some years ago I attempted to do something slightly odd for SQL auth in both, and found that postfix only let me use SASL, and SASL didn't have a driver for what I wanted, and therefore in order to make it do what I wanted I needed to write a C-based SASL driver to execute the SQL I wanted. In exim it was 3 or 4 lines of config. Similarly, if I hit something systemd can't do I now have to write C to add a config file, rather than write a couple of lines of shell. that is what the author means. I could certainly see an advantage to providing an ini-based approach as well for people who regard current LSB conmpliant init scripts as "shell scripts that made no sense to me" - and for people like me who -do- love them, but would be quite happy with a simple way to configure simple things. But please don't try and take that power away from me when I need it.