Hi, On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:
> As a lot of the conflict between sysvinit and systemd was about the > philosophy. I wouldn't say "philosophy". These are different technical designs, and each design has certain capabilities and limitations. It is not possible to build a design that has the strengths of both but none of the weaknesses, because you'd have to solve the halting problem for that. For a desktop environment it makes a lot of sense to have a microservice architecture such as the one that systemd provides. Typical desktop use cases are "connect these Bluetooth headphones" and "allow the user on the local console to select an active network card and configure settings". The network device configuration case is a simple policy decision. The logged-in user is the owner of the system and also the only stakeholder, so in this case it makes sense to provide an interface that allows a non-privileged user to perform a privileged action, limited by the expressiveness of the interface. The network configuration API does not allow setting up a complex routing table with multiple weighted alternatives, because that is not part of the use case, and that is fine. The bluetooth headset use case goes a bit beyond policy. There is still a system-wide element (hardware access only for the local user), but most of the software stack involved lives in userspace now and is orchestrated as microservices, including a mechanism to topple the entire stack on error. That is a sensible design choice -- if the user walks out of range with their headset, there is no sensible way to provide audio service, and the existing kernel audio APIs do not have an appropriate signaling mechanism. For servers, the benefit is rather limited. There is no local user who makes system-wide policy decisions, and hardware is not changing dynamically either. The actual services provided are either implemented as daemons (i.e. not microservices), or proper microservices run inside a site-wide microservice framework such as Docker+Kubernetes, because a system-local framework such as systemd is too limited to express the dependencies. System boot time is significantly less important than service response time, so "socket activation" for daemons is not useful in this context either. We have had this for -literally- decades in the form of inetd, and it has not been widely used, precisely for that reason. The "desktop" and "server" use cases are so vastly different that it doesn't make sense to try to squeeze both into a single design, because it will not be good at either. There are other use cases that have requirements that are not adequately serviced by either, for example embedded systems or containers. It is way more useful to have multiple alternatives that fit their respective use cases well than one thing that attempts to do everything. > So then the question boils down to what kind of feature > development sysvinit *in Debian* is willing to do to do that. If the > answer is "we really want the shell scripts as they have been since > the beginning of time - and that is the scope of sysvinit" (which > would not be true either, I know), then we cannot have that > discussion either. It is pretty close to the truth. The SystemV init design boils down to - there are two phases of system boot: kernel services (rcS.d) and user services (rc[1-5].d). User services can depend on kernel services. - configuration files are in an imperative language The systemd design on the other hand: - there is a dependency tree of services that may depend on each other - configuration files are descriptive, with an exception for generators, which are imperative, but generate descriptive configuration fragments The scope of sysvinit is to provide a minimal framework and then get out of the way. Daemons can expect a working file system and to be able to create listener sockets on INADDR_ANY or IN6ADDR_ANY. Anything beyond that is the responsibility of the daemon. The NTP daemon for some reason binds one socket per configured IP address, so it needs to watch for network configuration events. Offloading that responsibility into a common component would probably be possible, but would not save any complexity because the main task of coordinating these changes with the efforts to adjust the system clock would still be there. As a result, it doesn't make any sense to make ntpd dependent on systemd for its socket handling, and the only thing systemd is useful for is the same thing that sysvinit also does: start the daemon some time after early boot is complete. The sanest thing we could do in Debian is to teach start-stop-daemon to parse systemd .service files and pull its command line arguments from there, so we could use service definitions as init scripts with a #! line. For that to happen, we'd have to define .service files as an API though, which would feature-freeze them, and I'm not sure the systemd people would be happy about that. For systemd-only services, it makes the most sense to spawn a per-user systemd instance when they log into a graphical desktop environment. System-wide systemd-only services past the early boot stage are just bad design, do not currently exist and we shouldn't encourage their creation. Simon
