SystemD is blamed for long boot times and being heavy and bloated on resources. I tried OpenRC and Runit on real hardware (Ryzen 5000-series laptop) for week each and saw only 1 second faster boot time.
I’m old enough to remember plymouth.service (graphical image) being the most slowest service on boot in Ubuntu 16.04 and 18.04. But I don’t see that as an issue anymore. I don’t have a graphical systemD boot on my Arch but I installed Fedora Sericea and it actually boots faster than my Arch despite the plymouth (or whatever they call it nowadays).
My 2 questions:
- Is the current SystemD rant derived from years ago (while they’ve improved a lot)?
- Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
It’s not a daemon; it’s a command-line program that starts and stops daemons. It is specifically designed to be called from init scripts. It was originally developed for Debian in the '90s, and has been used in its init scripts ever since.
I’m not familiar with non-Debian distributions, but I assume they have their own equivalents, if they aren’t using a full-blown service manager like systemd.
An old pre-systemd CentOS machine I have access to uses some shell functions defined in
/etc/init.d/functionsto start and stop daemons. Those shell functions use therunuserprogram from the util-linux package to change user ID, notsu.Per the
systemd.serviceman page forRemainAfterExit: “Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no.” (Emphasis mine.)systemd-sysv-generatorgeneratesType=forkingservice units.Per the
systemd.serviceman page for this type of service: “If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main service process, and the service manager will consider the unit started when the parent process exits. This is the behavior of traditional UNIX services.”It would be counterproductive for systemd to kill all of the processes belonging to such a service when the parent process exits, since the whole point of this type of service is that the parent process exits immediately.
You might be thinking of how
logindby default kills all processes belonging to a user session when the session ends. That’s different from services, though.Works for me:
(
systemctl statusalso shows recent log entries, which I have omitted here.)Even with the extra fork, and even without a
PidFilesetting, it correctly identifies all of the processes belonging to this service, including the main process. And, even without anExecStopsetting telling it to useapachectl, it still correctly stops the service:(I have once again omitted the recent log entries from this output.)
runuser I do know and you’re correct it’s what is expected, and actually you CAN use su you just have to make sure you use the arguement that tells it not to follow a login process, but as a syaadmin myself, none of the guys I worked with, and none of the customers I had ever worked with hitting these issues had ever heard of it. But yes you can switch user without falling through the PAM stack and be fine.
As for the fork maybe they resolved that or maybe they made it better because you only have 1 child, but I can tell you I wouldn’t trust systemd that way personally from my experience. And yes Type=forking also says you should have a PIDFile and that’s in case there are multiple forks you can be explicit in which pid is thr parent. There are other issues you can get into like not setting ulimits or if you have 1 script that starts multiple daemons.