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