Il giorno gio 7 dic 2023 alle ore 22:53 Alexandros Prekates
<aprekates@???> ha scritto:

> With my limited relative knowledge from what you wrote i get the
> impression that the obstacles for runit to initiate - manage user
> services are (or at least seem to me) few (althought you seem to think
> that is not easy ). Mainly how to interoperate with a login or seat
> manager in order to initiate (user-init !) services on foouser login and
> terminate the foouser services when foouser logs out.

yes exclactly, some glue is needed

> So what is the biggest stumbling block ?
find the time to write the glue program and test it

> A login manager should start a user-init like linux kernel
> starts a system-init and login manager when accepting a terminate
> signal should stop the user's init which will take care of stopping
> the user's services gracefully. In that case you get two runit instances
> that could possible be unrelated. A system one and a user one.

roughly correct, but there's no need for two runit instances, you just
need two runsvdir instances, one system-wide and another one
specific for the user. This is already possible, you run the user
runsvdir as a system service and drop root privilege with chpst.

As for the missing glue, there are several approach: you can teach
the login manager how to start/stop a service, or you can incorporate
the glue into you init system/supervision system, or you can incorporate
everything into your init system, very systemd style.
My favorite is to have a program that is separate both from the login
manager and from the init system, so that it does only its specific
job and is reusable across different init systems.

Lorenzo

>
> Alexandros.