4 ms·

> You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by

> You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else. So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).

bipson 7y ago
For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.
- flukus 7y ago
  I've tried, it was more like 3 hours before I gave up and I was only writing it in the first place because systemd got involved where I didn't ask it too. All I did was mount a network drive from a shell script and systemd decided that it didn't know how to unmount it and instead hang for 90 seconds when the system shutdown. It leaks into user land.
  - pritambaral 7y ago
    Systemd defaults to the kernel's standard way of unmounting filesystems (i.e., umount(2)). You would have to write a .mount file only if your filesystem _couldn't_ be unmounted the normal way. The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too. > It leaks into user land. Init has always been in user land.
pritambaral 7y ago
> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise". 1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did. 2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files. The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV. Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files. > which may include network and container management, timers and God knows what else. 1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd. 2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files. > ... unless you are insisting on writing all your init files ... It's not an all-or-nothing affair. It never was, not with systemd not with SysV. > ... at which point you may as well use any of systemd alternatives Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
- MertsA 7y ago
  >Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false. Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up. With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.

bipson 7y ago

For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.

flukus 7y ago
I've tried, it was more like 3 hours before I gave up and I was only writing it in the first place because systemd got involved where I didn't ask it too. All I did was mount a network drive from a shell script and systemd decided that it didn't know how to unmount it and instead hang for 90 seconds when the system shutdown. It leaks into user land.
- pritambaral 7y ago
  Systemd defaults to the kernel's standard way of unmounting filesystems (i.e., umount(2)). You would have to write a .mount file only if your filesystem _couldn't_ be unmounted the normal way. The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too. > It leaks into user land. Init has always been in user land.

pritambaral 7y ago

> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise". 1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did. 2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files. The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV. Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files. > which may include network and container management, timers and God knows what else. 1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd. 2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files. > ... unless you are insisting on writing all your init files ... It's not an all-or-nothing affair. It never was, not with systemd not with SysV. > ... at which point you may as well use any of systemd alternatives Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.

MertsA 7y ago
>Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false. Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up. With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.