Some people think it handles too many low-level systems. It’s a valid concern because if systemd itself were to become compromised (like Xz Utils was) or a serious bug was introduced, all of the userland processes would be affected. People who are stuck in the 90s and think that the Unix philosophy is still relevant will also point out that it’s a needlessly complex software suite and we should all go back to writing initscripts in bash. The truth is, it’s complex because it needs to solve a complex problem.
Red Hat, the owner of systemd, has also had its fair share of controversies. It’s a company that many distrust.
Ultimately, those whose opinion mattered the most decided that systemd’s benefits outweigh the risks and drawbacks. Debian held a vote to determine the project’s future regarding init systems. Arch Linux replaced initscripts because systemd was simply better, and replicating and maintaining its features (like starting services once their dependencies are running) with initscripts would’ve been unjustifiably complicated.
Systemd does one thing, it manages services, and does so reliably, without messing around with spagettified shell scripts, with a fuckload of options, and all of that easily is configurable by dropping in files without editing stuff that arrived from the package manager. Seems pretti “do one (complex) thing and do it well”
If you add other things built around it, it can do more. For example, if you install systemd-nspawn it can start and stop containers like it starts and stops services.
Other things that you think of as systemd are entirely separate things (like systemd-networkd) that are just built around systemd. You don’t have to use them if you don’t like.
On the other hand, you know what does not follow the Unix philosophy? The Xserver, which manages screens, graphic acceleration, input devices, printers, remoting, etc. And it doesn’t even do it well
I need systemd-run to start a process in my startup scripts (that are a systemd oneshot service) so that the process won’t get killed when the startup scripts have run (subshells, nohup, … still keep the same systemd cgroup so get killed with the tree).
I need journalctl to get output from services, so basically every system and user process I didn’t explicitly start in a console. I don’t even know how to get info from systemd stuff in any other way, as they don’t have alternate logging facilities to my knowledge.
Systemd also ate my fstab at some point and translates mounts into services, but I haven’t really looked into that.
I think there were a few more components packed into this systemd core. Without the init system/servixe manager, logging, … you can’t really use systemd stuff including parts of that core.
Past that, things like networkd, resolved, … are very modular in my experience.
I can imagine running resolved under a different init system, and I have migrated both to and from resolved on systemd systems. They do still change old paradigms, resolved replaces a file not a service for example, but they do provide adequate translation layers and backwards compatibility in most cases (Though the mounts for example has lead to me getting 5 “run daemon-reload” info messages on every execution of mount before). An issue here might be when something only supports the new systemd interface not the old stuff, say a program directly calling resolved instead of looking at resolv.conf. But I haven’t seen that, and most of those interfaces seem decent enough to implement into systemd-alternatives.
Maybe someome who actually tried cherrypicking some systemd stuff into their system can provide some more experience?
Fstabs gets converted into temporary unit files every time systems reloads config files (reboot or daemon-reload) so you can just keep using it like you always did. Actually it’s the systemd suggested way to manage mountpoints unless you need something advanced that fstabs can’t do.
My problem is 1) how do I revert to dedicated mount, and 2) mainly that I want to edit fstab, and mount without having to reload systemd. Dedicated mount doesn’t need a reload, it simply pulls config from fstab at time of call.
I also don’t see why you would ever want to reload service files due to editing fstab, it seems dumb in both directions. Those two systems should just be decoupled.
Fstab is still there untouched, it’s the temporary units files that get replaced at reload.
The mount program works as normally, if you edit fstab and then mount -a it will work as expected, it will just warn you that systemd is not aware of the change. It will reload it anyway at the next boot.
daemon-reload is not daemon-restart, it just makes systemd re-read the configuration to make it aware of the changes, but the services don’t get restarted. Some services (e.g. nginx) can re-read their confuration without restarting, those services are also made aware of the changes when reloading and can be reloaded individually.
You can edit any systemd units using systemctl edit so you don’t need to reload (fstab is not a systemd unit)
You probably mean daemon-reexec, which also does not restart services (it better not, would be really problematic if it did).
I do mean reload, which has uses, otherwise it wouldn’t even exist and services would simply always reload: You may not want to reload yet, but keep a working state of service definitions in systemd while editing things, similar to typing away in a code file in production without saving yet.
I don’t see why I would need to “save” all my service definitions to get a usable (non-spammy) mount back, especially when my mount isn’t even part of systemd. How does the message even get sent by mount when mount is not aware of systemd?
PS: systemd can replace my text editor over my cold dead body
It doesn’t replace the editor, it creates a stream and opens it in your default text editor. When you write out, it saves the stream to an appropriate drop in file
That’s not true at all? I don’t think they use multicall binaries and both systemd-boot and udev (I don’t remember any other util that became part of systemd) are still separate. And every other utility under systemd umbrella is separate as well.
As for philosophy, no unix ever even tried in any way to embody this.
shutdown, reboot, … are symlinks on multiple different systemd repos, I have no reason to believe that is not the systemd standard.
systemd is not moving all it does into a single binary, obviously. Others already mentioned that and a bit further up I mentioned some systemd components that can be isolated too.
GNU posix is one extreme, and busybox the other, and the accusation is that the core of systemd sits too close to busybox, and the other projects might too group together things into fewer binaries that used to be multiple independent commands.
As for the core, I think that constitutes: services, logging (journald), cron+anacron (timers), blocking (systemd-inhibit), and mount.
I am probably missing some there. Timers does not interfere with other cron, but it is there whether you like it or not. Those components also come bundled with otherwise optional linux features like cgroup which do complicate using other posix tools with systemd, as you get unexpected results (like nohup not working).
OOL: what’s the beef with systemd?
I’ll just copy my comment from the other day.
Some people think it handles too many low-level systems. It’s a valid concern because if systemd itself were to become compromised (like Xz Utils was) or a serious bug was introduced, all of the userland processes would be affected. People who are stuck in the 90s and think that the Unix philosophy is still relevant will also point out that it’s a needlessly complex software suite and we should all go back to writing initscripts in bash. The truth is, it’s complex because it needs to solve a complex problem.
Red Hat, the owner of systemd, has also had its fair share of controversies. It’s a company that many distrust.
Ultimately, those whose opinion mattered the most decided that systemd’s benefits outweigh the risks and drawbacks. Debian held a vote to determine the project’s future regarding init systems. Arch Linux replaced initscripts because systemd was simply better, and replicating and maintaining its features (like starting services once their dependencies are running) with initscripts would’ve been unjustifiably complicated.
it does too many things, thus going against the unix philosopy of “do one thing and do it well”
Systemd does one thing, it manages services, and does so reliably, without messing around with spagettified shell scripts, with a fuckload of options, and all of that easily is configurable by dropping in files without editing stuff that arrived from the package manager. Seems pretti “do one (complex) thing and do it well”
If you add other things built around it, it can do more. For example, if you install systemd-nspawn it can start and stop containers like it starts and stops services.
Other things that you think of as systemd are entirely separate things (like systemd-networkd) that are just built around systemd. You don’t have to use them if you don’t like.
On the other hand, you know what does not follow the Unix philosophy? The Xserver, which manages screens, graphic acceleration, input devices, printers, remoting, etc. And it doesn’t even do it well
I need systemd-run to start a process in my startup scripts (that are a systemd oneshot service) so that the process won’t get killed when the startup scripts have run (subshells, nohup, … still keep the same systemd cgroup so get killed with the tree).
I need journalctl to get output from services, so basically every system and user process I didn’t explicitly start in a console. I don’t even know how to get info from systemd stuff in any other way, as they don’t have alternate logging facilities to my knowledge.
Systemd also ate my fstab at some point and translates mounts into services, but I haven’t really looked into that.
I think there were a few more components packed into this systemd core. Without the init system/servixe manager, logging, … you can’t really use systemd stuff including parts of that core.
Past that, things like networkd, resolved, … are very modular in my experience.
I can imagine running resolved under a different init system, and I have migrated both to and from resolved on systemd systems. They do still change old paradigms, resolved replaces a file not a service for example, but they do provide adequate translation layers and backwards compatibility in most cases (Though the mounts for example has lead to me getting 5 “run daemon-reload” info messages on every execution of mount before). An issue here might be when something only supports the new systemd interface not the old stuff, say a program directly calling resolved instead of looking at resolv.conf. But I haven’t seen that, and most of those interfaces seem decent enough to implement into systemd-alternatives.
Maybe someome who actually tried cherrypicking some systemd stuff into their system can provide some more experience?
Fstabs gets converted into temporary unit files every time systems reloads config files (reboot or daemon-reload) so you can just keep using it like you always did. Actually it’s the systemd suggested way to manage mountpoints unless you need something advanced that fstabs can’t do.
My problem is 1) how do I revert to dedicated mount, and 2) mainly that I want to edit fstab, and mount without having to reload systemd. Dedicated mount doesn’t need a reload, it simply pulls config from fstab at time of call.
I also don’t see why you would ever want to reload service files due to editing fstab, it seems dumb in both directions. Those two systems should just be decoupled.
Fstab is still there untouched, it’s the temporary units files that get replaced at reload.
The mount program works as normally, if you edit fstab and then
mount -ait will work as expected, it will just warn you that systemd is not aware of the change. It will reload it anyway at the next boot.daemon-reload is not daemon-restart, it just makes systemd re-read the configuration to make it aware of the changes, but the services don’t get restarted. Some services (e.g. nginx) can re-read their confuration without restarting, those services are also made aware of the changes when reloading and can be reloaded individually.
You can edit any systemd units using
systemctl editso you don’t need to reload (fstab is not a systemd unit)You probably mean daemon-reexec, which also does not restart services (it better not, would be really problematic if it did).
I do mean reload, which has uses, otherwise it wouldn’t even exist and services would simply always reload: You may not want to reload yet, but keep a working state of service definitions in systemd while editing things, similar to typing away in a code file in production without saving yet.
I don’t see why I would need to “save” all my service definitions to get a usable (non-spammy) mount back, especially when my mount isn’t even part of systemd. How does the message even get sent by mount when mount is not aware of systemd?
PS: systemd can replace my text editor over my cold dead body
It doesn’t replace the editor, it creates a stream and opens it in your default text editor. When you write out, it saves the stream to an appropriate drop in file
See also: the Linux Kernel
Shouldn’t init systems control services and processes?
There is no such philosophy and it was never practiced.
Unix is where the model of linux commands originates, and those commands absolutely embody the unix philosophy.
Systemd is a bit like busybox in that many formerly standalone comands turn into symlinks to systemctl.
Take a look at shutdown for example.
That’s not true at all? I don’t think they use multicall binaries and both systemd-boot and udev (I don’t remember any other util that became part of systemd) are still separate. And every other utility under systemd umbrella is separate as well.
As for philosophy, no unix ever even tried in any way to embody this.
shutdown, reboot, … are symlinks on multiple different systemd repos, I have no reason to believe that is not the systemd standard.
systemd is not moving all it does into a single binary, obviously. Others already mentioned that and a bit further up I mentioned some systemd components that can be isolated too.
GNU posix is one extreme, and busybox the other, and the accusation is that the core of systemd sits too close to busybox, and the other projects might too group together things into fewer binaries that used to be multiple independent commands.
As for the core, I think that constitutes: services, logging (journald), cron+anacron (timers), blocking (systemd-inhibit), and mount.
I am probably missing some there. Timers does not interfere with other cron, but it is there whether you like it or not. Those components also come bundled with otherwise optional linux features like cgroup which do complicate using other posix tools with systemd, as you get unexpected results (like nohup not working).
It’s definitely a thing.
https://en.m.wikipedia.org/wiki/Unix_philosophy
I don’t disagree that term itself exists of course. But it was and is bullshit that those philosophers themselves never actually followed.