:: Re: [DNG] (runit) Can emacs daemon …
Top Page
Delete this message
Reply to this message
Author: Arnt Karlsen
Date:  
To: dng
Subject: Re: [DNG] (runit) Can emacs daemon become a user service ?
On Fri, 8 Dec 2023 12:36:08 +0100, Lorenz wrote in message
<CAOEhTLzBONWUvMkngaaMrE7LrFSBCt0CxcBiQwFb77hKNhzM_Q@???>:

> 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



...each specific user (or group of users), rather than...

> the user.


..even I as the egalitarian Norseman, can see a use for hiearchy of
compartmentalized users, e.g. a mutt user to read root's mail, a tor
browser user to blow the whistle on a genocider, a tor browser user
for embarrassing porn etc, etc.

> 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.


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.