Re: [skaware] non privileged user oneshots/services launched by root not requiring the user to login 1st (like systemd @user ones) support

[Laurent Bercot]

 User services come with their own batch of design questions to solve,
which are pretty different from the questions raised by system services.
And most of these questions are policy-related, i.e. there's no obvious
answer but the answers strongly depend on what exactly the users want
and how the distribution usually organizes things.

 It is difficult for s6 to answer these questions, which is why I
haven't tried tackling user services yet - save for s6-usertree-maker
which is a pure mechanism helper for users and distributions, and far
from a complete implementation of user services.

 In a few years or so, when the s6 ecosystem is widely deployed as
a full-featured init system on several distributions and there are
experience returns on how they like to handle user services, I may
attempt to provide a unified solution.

--
 Laurent

Re: [skaware] non privileged user oneshots/services launched by root not requiring the user to login 1st (like systemd @user ones) support

[Casper Ti. Vector]

On Thu, Oct 28, 2021 at 06:17:52PM -0600, Javier wrote:
> I use s6 on artix gnu+linux, and I think I'm missing support for
> oneshots/services like the systemd @user ones.  Those are still
> launched automatically when the system (not the user) starts.

The following may help as well:
.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: [skaware] non privileged user oneshots/services launched by root not requiring the user to login 1st (like systemd @user ones) support

[Carlos Eduardo]

> 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  escreveu:
>
> Hello !
>
> I use s6 on artix gnu+linux, and I think I'm missing support for 
> oneshots/services like the systemd @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  @
>
> 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