dynamic services (and user services kindof)

[navi-desu]

okay, for context, currently the user services branch is implemented in way by a very barebones, c-api only dynamic services; so before i scratch all that in favor of another implementation, i wanted to open a discussion

dynamic services is what i'm naming an openrc equivalent to systemd's [email protected] being auto-instantiated to [email protected], when for example, a service tries to depend on foo@nya or an user tries to start foo@nya

--

the implementation currently uses the same heuristics we already do to determine what configurations to load, that is to say, the service name up until the first dot, since starting init.d/net.eth0 loads up conf.d/net as well as conf.d/net.eth0

dynamic services would use the same heuristic to instantiate services, that is to say, when a service does depend() { need foo.nya }, and init.d/foo.nya does not exist, but init.d/foo does exist, then openrc would make a symlink /run/openrc/dynamic/foo.nya -> /etc/init.d/foo, and use that to resolve foo.nya (configurations are loaded 'as-if' the service was on the same folder as the base, so in this case, /etc/conf.d/foo and /etc/conf.d/foo.nya would both be loaded)

it could be also made so an user running rc-service foo.nya start would trigger the same procedure

--

there was pushback against this. in a technical matter, this require us to allow service symlinks to live outside the init.d (as they'd be in /run/openrc), however i do believe to have solved any potential issues with this

there was also the question of complexity, that this feature would feel too "automagical"

it's use within openrc --user was brought about for a want of simple and reusable code, since we could reuse the pre-existing service management logic to manage user services, reduce the need for synchronizing state with pam, and so on.

but there is also the argument of simplicity, by supporting that system directly on the pam module, and limit the scope of features wrt how "dynamic" the service management in openrc is. and i do have a good idea of how to implement the pam module and user service without all this "dynamic" stuff

--

so i wanted to ask for a discussion, and in general gather if people are in favor or against such feature before i work on it more, as currently i'm torn on what is the best approach.

and anyway, thanks!

[skarnet]

I call these instantiated services where nya is the instance parameter. I prefer to reserve the term "dynamic services" to something different: services that are started/stopped as a consequence of dynamic events during the lifetime of the machine. Unless I missed something, openrc doesn't handle dynamic events, and that's why stuff like a network manager is needed, because the network is inherently dynamic - you can't accurately predict at boot time what network interfaces will be up and when.

I've thought for a long while about instantiated services (foo@nya) for s6-rc v1, and my conclusion was: it's fine, as long as you don't try too hard to make a completely consistent dependency model. More precisely, you can have instances depend on normal services, and you can reasonably have foo@X depend on bar@X for all X (which we would express as foo@ depending on bar@), but that's about it. Anything more complex than that and it's easy to get lost in the weeds - it happened to me, 2/10, wouldn't recommend.

I also don't understand the relationship to user services. They seem pretty orthogonal to me: the root service set can have normal or instantiated services, and so do services declared by users? But maybe I'm missing something.

In short: instances are cool, and relatively easy to code (for you) and understand (for users) as long as you stay with a simple, heavily restricted, dependency model. Beyond that, it's madness.

[navi-desu]

I also don't understand the relationship to user services

sorry, i should've specified, but it's how we start "openrc --user" for any given user.

with it, openrc-pam would create an instance of user.<username> and start it, and stop it at login, this gives us the benefit of using openrc's existing management utilities to manage users, and to re-use the same service to start/stop user-services with runlevels (aka "auto start at boot" which many people asked me about supporting)

without it, openrc-pam would itself manage the state of the user session (using /run/openrc/user/<username> to keep state), and the system-wise user script would work like an usual script that the user adds to a runlevel if they want "auto start at boot"

More precisely, you can have instances depend on normal services, and you can reasonably have foo@X depend on bar@X for all X

the current implementation i have is a bit more powerful, with no extra complexity. since it's symlinks with the same heuristics as config loading, foo.<here_anything_goes> and the logic is exact the same as if it was the same X, because it doesn't care about the X of the instantiator, only the instantee (idk if those are words that exist or not)

Unless I missed something, openrc doesn't handle dynamic events

it, kinda does kinda doesn't? we have the concept of hotplugged services, which are meant to be triggered by the system as a reaction to something else (e.g. udev starts the driver for a device hotplugged), in practice, it means that hotplugged services will live across runlevel changes, and only stop when explicitly said to