Hello, 2017-06-26 12:05 GMT-03:00 Istvan Szukacs: > > [...] I do not want > logging, ntp and all the other crap that got sucked into it. I understand > that service files are much better that shell scripts and this is a good > argument but it does not justify the idiocracy that systemd became in the > recent years. Ideally we could have a service (like s6) that does only that > keeping the best parts of systemd as well. This would allow me to run > redhat/centos based systems and use service files without being worried > that a huge amount of CPU cycles going to a service that sole purpose is to > keep services up that actually provide the functionality that I need. Does > this clarify?
I'm partially repeating what others have said, but the way I see it: You seem to be focused only on systemd unit files. An alternative init system that understands unit files doesn't work as a drop-in replacement. 1) systemd, the package, is not 'just' an init system. It is a whole set of low-level userland components, that happens to include among them a program intended to run as process 1 (also named 'systemd'). Some of the components can work without systemd (the program) being process 1, like systemd-udevd, and maybe libsystemd (I don't know for sure). Others, like systemd-logind, cannot. And software packages may depend on any of those components. For example, GNOME desktop components do not actually care about the init system, but do want to be able to send messages over D-Bus to a server implementing the logind API (as far as I understand). 2) Package dependencies and binary-based distributions. A lot of software packages that have a real dependency on systemd (a package that only provides a unit file does not qualify as having a dependency), have an optional compile-time one (e.g. './configure --with-systemd'). But if developers of a GNU/Linux distribution choose to build the package with the option turned on, it becomes a mandatory runtime dependency for the user. Maybe the dependency is on a component that doesn't care who's process 1 and you are lucky, or maybe not. And if that is done with every package shipped by the distribution, the result is an entanglement with systemd you can't get out of. So once a binary-based distribution decides to get married to systemd, I think it is safe to assume that it is a one-way ticket. So it might be possible to have GNU/Linux and not systemd, but highly unlikely (IMO) if we are talking RHEL or CentOS. > # rpm -q --requires openssh-server | grep systemd | sort -u > libsystemd.so.0()(64bit) > libsystemd.so.0(LIBSYSTEMD_209)(64bit) > systemd-units > > I am not sure why any service would depend on these. Is there functionality > in libsystemd.so.0 that an ssh service actually needs? If that's the software from www.openssh.org, Gentoo's packaging of it [1] does not list systemd as a dependency, not even conditionally on a USE flag. I'm guessing that what is shown here is some indirect dependency through PAM. G. [1] https://packages.gentoo.org/packages/net-misc/openssh
