3 ms·

The argument is one of minimizing attack surface, not specific current attacks. I.e. it's a question of selecting the right technology security-wise and attack

The argument is one of minimizing attack surface, not specific current attacks. I.e. it's a question of selecting the right technology security-wise and attack surface is a big part of that equation because with that surface area comes the strong likelihood that attacks will be found against the process over time. I use systemd because that's what my distro comes with. There are positives and negatives. On the whole though, I agree with much of the criticism, and I hope that a real alternative comes along which is more security and uptime friendly.

TheCondor 13y ago
How has it affected your uptime? Any specifics?
- einhverfr 13y ago
  In addition to the prudential concern issues (which are laid out in the article), there are some concrete issues: With sysv init, it is very easy to add new services that may not be supported out of the box. There are scripts like rc.local, etc, which can be edited to start anything. This means that setting up a new service that can be supported properly is a lot more work, especially if it is for development systems. While I haven't had systemd crash, I have had issues with stuff requiring manual start (i.e logging in as root and running the startup script for the app) when a simple rc.local-type approach would have been far simpler. Another problem I have had is the issue of process accounting, where if the process starts up a daemon and exits, then systemd has trouble determining the status properly. This can cause issues for things like monitoring (which means basically I don't use systemd for monitoring whether services are running). What this means, in essence, is that to make this work the way I would like I have had to reinvent part of the sysv init system inside of systemd and then handle things like process tracking the old fashioned way (pid files and shell scripts). In short, in addition to the "I don't want my system to have to reboot and this is a bad architecture for that requirement" you have quite a bit of areas where there are leaky abstraction layers which don't really add any benefit to administration of the system.
  - tmzt 13y ago
    That sounds strangely like the problem systemd was created to solve. It's supposed to detect double forks in the started daemon and track pid files named in it's configuration file. At least that's how I read it in numerous articles on LWN and mailing lists, I haven't tried it on an actual system yet.

TheCondor 13y ago

How has it affected your uptime? Any specifics?

einhverfr 13y ago
In addition to the prudential concern issues (which are laid out in the article), there are some concrete issues: With sysv init, it is very easy to add new services that may not be supported out of the box. There are scripts like rc.local, etc, which can be edited to start anything. This means that setting up a new service that can be supported properly is a lot more work, especially if it is for development systems. While I haven't had systemd crash, I have had issues with stuff requiring manual start (i.e logging in as root and running the startup script for the app) when a simple rc.local-type approach would have been far simpler. Another problem I have had is the issue of process accounting, where if the process starts up a daemon and exits, then systemd has trouble determining the status properly. This can cause issues for things like monitoring (which means basically I don't use systemd for monitoring whether services are running). What this means, in essence, is that to make this work the way I would like I have had to reinvent part of the sysv init system inside of systemd and then handle things like process tracking the old fashioned way (pid files and shell scripts). In short, in addition to the "I don't want my system to have to reboot and this is a bad architecture for that requirement" you have quite a bit of areas where there are leaky abstraction layers which don't really add any benefit to administration of the system.
- tmzt 13y ago
  That sounds strangely like the problem systemd was created to solve. It's supposed to detect double forks in the started daemon and track pid files named in it's configuration file. At least that's how I read it in numerous articles on LWN and mailing lists, I haven't tried it on an actual system yet.