Aigars Mahinovs wrote: > On 28 October 2014 12:12, Josselin Mouette <j...@debian.org> wrote: > > This is nice and all, but how to you tell such a “sub-init” which > > services have been already started and which services it has to start > > itself? > > The point of a sub-init would be to start one specific service. > Basically the idea would be that in /etc/init.d/gdm3 init script, > instead of starting the gdm daemon, one would start systemd with a > very special set of configurations (possibly even separate and > different from what one would use in a normal, systemd-based startup > of gdm). And on stopping of that service one would stop that whole > sub-init.
I actually think it would prove easiest to have one system-wide instance of systemd, whether in --system or --user mode. That way, services that use systemd to launch can declare dependencies on other such services, and things like sockets.target (the point at which systemd has opened all socket-activation sockets) will work. That instance of systemd would also provide DBus services. --user might make it easier to get systemd to skip the various system initialization tasks it normally runs, assuming --user will run without a system instance running; --user would also automatically skip all of the services in /lib/systemd/system and /etc/systemd/system. On the other hand, --user may not permit many of the security directives services would like to use, such as User= or Group=, even if running as root. This needs some further exploration and possibly improvement. In a sub-init configuration, systemd itself would start either from inittab or from a relatively early init script. Packages and services would fall into two categories: those that provide both an init.d script and systemd configuration, and those that *only* provide systemd configuration and require systemd as sub-init (or systemd as init) to run. systemd running in this mode should theoretically provide enough DBus functionality to successfully run logind and similar services. In particular, systemd running in this mode could launch and manage dynamic slices and scopes. Packages and services that want to use systemd-specific functionality would then ship: - The usual configuration (.service, .socket, etc) for the normal case of systemd running as PID 1, in /lib/systemd/system and similar. - A nearly identical configuration (potentially with somewhat different dependencies) in some dedicated directory for systemd-as-a-sub-init. Frequently, this may simply consist of a copy of the configuration for the previous case. This is kept separate because a package cannot launch via systemd on a sysvinit system unless additional conditions are met, primarily around dependencies. Plus, we can't use the services in /lib/systemd/system since that will also contain the services systemd should only run when running as PID 1. To the extent we can avoid dependencies from systemd services to sysvinit scripts or vice versa, that would suffice. In particular, a systemd service can depend on other systemd services shipped by other packages, so if the package's surrounding ecosystem supports running via systemd the package can too. I can see several ways that we could handle dependencies between systemd services and init scripts, depending on what degree of interoperability we need. Given the high degree of interest in providing native systemd services for as many daemons as possible, I'd expect the transition period to prove relatively short. If we want to handle all dependencies from systemd services to init.d scripts systematically, we could have a generator that creates a .service for every init.d script, that does not actually *run* the script, but instead allows sysvinit to do so, and just waits for the script to reach the desired state. We could trivially make /etc/init.d/rc touch /run/init.d.started/$scriptname after running a script, or have /lib/lsb/init-functions do that (and require scripts to source that); the generated .service could then wait for that file to exist. On a case-by-case basis, an init script could also set up the same thing itself. However, it seems easier to do this systematically. Conversely, if an init.d script needs to depend on a systemd service, the package shipping the systemd service could ship a trivial init script that does not actually launch the service, but instead invokes a systemd command to wait for the service to become ready. That init script would need to have LSB headers, and those headers would include a dependency on the systemd init script. This should all work incrementally, with the cross-init-system dependencies becoming less relevant as more packages start shipping native systemd services (which many people have an interest in helping with, myself included). As an alternative approach, we could rely entirely on sysvinit and LSB dependencies, and just have packages dynamically launch a specific systemd unit. However, that would completely break the ability to use systemd dependencies, so I don't think that makes sense going forward. I'd be happy to help work on a coexistence solution like this, *if* it would actually end the interminable arguments over running systemd as PID 1. Any chance of it doing so? - Josh Triplett -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141028135809.GA5927@thin