> Using *s6-setuidgid* doesn't work for some scenarios, like automatically launching a screen session running rtorrent for a particular user.
I've had similar problems and came to learn that plain s6-setuidgid
doesn't set some variables that are relevant for user processes,
especially your HOME directory, which might cause programs to try to
load root's config files rather than yours.
If that ends up being your problem, the simplest solution (and it
doesn't require special support in s6) is adding the following lines
to your rtorrent daemon (or, if you're using a setup like mine for
user services, the user s6-svscan service, which will then propagate
to all daemons running under it):
> backtick HOME { homeof yourusername } export LOGNAME yourusername prog ...
If you add your user service to the bundle that gets brought up upon
system initialization (in Artix's case, default), it'll also run
headless even before you even login (actually, making services only
run on user login is more work than keeping them running at all
times).
If you're interested you might want to give Suite 66 (a wrapper for
s6) a try -- it's also available for Artix, and comes with a
ready-to-use user services feature.
also: remember s6-rc-bundle-update is an Artix-specific command.
Em qui., 28 de out. de 2021 às 21:18, Javier <je-vv_at_e.email> escreveu:
>
> Hello !
>
> I use s6 on artix gnu+linux, and I think I'm missing support for oneshots/services like the systemd _at_user ones. Those are still launched automatically when the system (not the user) starts. Using *s6-setuidgid* doesn't work for some scenarios, like automatically launching a screen session running rtorrent for a particular user. I might also be interesting on launching some other oneshots/services, without the requirement to login 1st as that particular user, to make the system sort of work automatically as headless (even though it can be interactively used by those users eventually).
>
> Perhaps:
>
> > s6-rc-bundle-update add <bundle> <oneshot|service>_at_<user>
>
> Might be a way to register for such non privileged users. Of course, underneath, there should be an automatic non interactive login, allowing running the oneshot/service as that user, having access to what the user have access to when it logins, including user directories, and the ability to run sessions such as screen ones...
>
> Hopefully you can consider adding such functionality...
>
> Thanks !
>
> --
> Javier
Received on Fri Oct 29 2021 - 04:18:11 CEST