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
Received on Thu Jun 29 2017 - 02:07:25 UTC