[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dng
Subject:    Re: [DNG] (runit) Can emacs daemon become a user service ?
From:       Martin Steigerwald <martin () lichtvoll ! de>
Date:       2023-12-07 8:27:08
Message-ID: 1761789.QkHrqEjB74 () lichtvoll ! de
[Download RAW message or body]

Lorenz via Dng - 07.12.23, 01:27:13 CET:
> So it seems logical to me at that point to have emacs as a user service.
> > But as mentioned in (4) that even if i set seperate runsvdir to start
> > for a user that would start before the user login. So emacs could not
> > used for example  XDG_RUNTIME_DIR to create a per user socket.
> > 
> > So is it that runit does not support user services  in a more
> > complete level or there is a way to have user services start per user
> > login event ?
> This is true, and I think no other init system has an feature fully
> equivalent to systemd --user.

That is something I had a go at with my user-services approach quite a 
while ago. However I was not really entirely happy with the approach so I 
did not continue it. It was on Devuan's Gitlab, but I now just uploaded it 
to Gitea:

https://git.devuan.org/martin/user-services

Anyway, it worked well enough for running Pulseaudio and Redshift at the 
time it was not (yet) run automatically on systems with other init than 
Systemd, at least not within a KDE Plasma session.

> For now I suggest you rely on something else to create the link/enable
> the nested user-runsvdir on user login and remove the link on user
> logout. For example many desktop have some "session configure panel" to
> set components that are automatically started with the desktop at
> login; you can run a script that creates the link from there.

Above approach just hooks into Plasma desktop startup, output from the 
install or upgrade script:

> KDE Plasma desktop session detected. Installing user services
> startup script to '~/.config/plasma-workspace/env'…

So if you use something different you need to use a different approach. I 
bet what would always work is to stuff it into some shell startup file for 
the user session like '.bashrc' or '.zshrc'. In case you like to start 
something that depends on DBUS or SSH agent for example you need to make 
sure to add it after their environment variables are set up.

> Not sure there is a proper way to run an action on logout..
> None of the above looks satisfying to me but I'm afraid there is no
> better way right now.

Above user-services approach worked well enough for me. However… I still 
felt it was a bit hackish and was not entirely satisfied with it (see 
below). At the moment I do not need it, as Pulseaudio nowadays is started 
automatically. Also the functionality of redshift is integrated in Plasma 
nowadays.

But anyway, maybe it is an approach that can work for you, Alexandros. It 
even had some primitive shell scripted usability boilerplate as explained 
in the markdown documentation.
 
> As a side note:
> * I don't believe this feature belongs to an init system, but it would
> be better to be implemented as a set of init independent services that 
> can be run by any init that is capable of someting like runit's nested 
> runsvdir

A kind of a wrapper for Runit and probabaly other service supervisors like 
S6? I thought about making user-services generic at some time, but as I 
was not entirely convinced by the approach and there has been other stuff 
going on I did not follow up on it. Here was what I thought back then:

On the other hand I thought how cool would it be having runit's sv command 
work just like it does with runit system services. Confused about which 
which approach to choose I stopped working at user-services. According to 
your feedback having an own command for user services that can hook into 
different service supervisors would be the approach to choose. And 
considering it today, it does make some sense. Having "sv" just work for 
user services would be a bit in the direction of an integrated approach as 
Systemd is using. So having a generic wrapper for user services may be 
preferable.

Currently the user-service "command" is just an alias to some shell code. 
But of course this could be changed.

> * I had an idea and started working on a draft last february but then
> run out of time and stopped, so nothing usable yet. I'll write on this 
> list asking for testers if/when I finish that.

Did you upload the source anywhere? Would like to see what your approach 
was.

Well at least I re-uploaded my user-services approach. Maybe it is handy 
for some.

Ciao,
-- 
Martin


_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[prev in list] [next in list] [prev in thread] [next in thread]