Shepherd user services that run on startup?

Shepherd user services that run on startup?

[Ben Weinstein-Raun]

Hello! I'm fairly new to using Guix System, and I have a lot of questions.

One is: Is it possible to run a shepherd user service at system start, 
rather than at login?

My guess is that this is at least possible, by defining a system-level 
service that starts a shepherd for each user. Would that work?

Anyone have tips on how to go about building this, if so? Especially: 
What's the easiest way to ensure that a guix service knows the list of 
users-with-login-shells on the system? And easiest way to run a 
`shepherd` instance as each such user on startup? I'm working on writing 
a service definition, but as this is my first from-scratch service (guix 
or shepherd), and one of my first lisp projects since reading SICP 15 
years ago, it's slow going (even with the reference manual and source 
code of other services).


And, of course, is there a simpler way?


(I also asked this question on the r/guix subreddit, but haven't heard 
anything yet, and figured I'd ask here too)

Re: Shepherd user services that run on startup?

[Csepp]

Ben Weinstein-Raun <root@benwr.net> writes:

> Hello! I'm fairly new to using Guix System, and I have a lot of questions.
>
> One is: Is it possible to run a shepherd user service at system start, 
> rather than at login?
>
> My guess is that this is at least possible, by defining a system-level 
> service that starts a shepherd for each user. Would that work?
>
> Anyone have tips on how to go about building this, if so? Especially: 
> What's the easiest way to ensure that a guix service knows the list of 
> users-with-login-shells on the system? And easiest way to run a 
> `shepherd` instance as each such user on startup? I'm working on writing 
> a service definition, but as this is my first from-scratch service (guix 
> or shepherd), and one of my first lisp projects since reading SICP 15 
> years ago, it's slow going (even with the reference manual and source 
> code of other services).
>
>
> And, of course, is there a simpler way?
>
>
> (I also asked this question on the r/guix subreddit, but haven't heard 
> anything yet, and figured I'd ask here too)

Not a direct answer, but this seems similar to systemd's linger
functionality, that might be worth taking a look at.

Re: Shepherd user services that run on startup?

[Hipólita Yarona]

On Thu, Dec 28, 2023 at 8:43 PM Csepp <raingloom@riseup.net> wrote:
> Ben Weinstein-Raun <root@benwr.net> writes:
>
> > Hello! I'm fairly new to using Guix System, and I have a lot of
> > questions.

So am I, so do I.

> > One is: Is it possible to run a shepherd user service at system
> > start, rather than at login?
> >
> > My guess is that this is at least possible, by defining a
> > system-level service that starts a shepherd for each user. Would
> > that work?
> >
> > Anyone have tips on how to go about building this, if so?

I'll let others reply on behalf of Guix and Shepherd.  What I'll add is
a reinforcement of your idea, but which drifts apart from the Guix
system.  You can use Daniel J. Bernstein's daemontools

  http://cr.yp.to/daemontools.html,

which is already packaged in Guix --- guix install daemontools.  You can
write a service for Shepherd to start daemontool's svscan and now you
can manage all your services outside Shepherd, including user's services
--- so long as you complement the system in one small way.

With svscan starting at boot, letting users run their own services at
boot as well is a matter of writing a program with the setuid-bit so
that it is able to create symbolic links in the directory monitored by
svscan (say, /service) --- enabling the user's service to be managed by
svscan.  That would accomplish what you ask.

Many system administrators will not let users create as many services as
they want.  You need to answer these questions.  Say you'd like to allow
users to have up to a few services --- tprogram-idea above could control
that by counting how many the users has already used.

Here's what the user would go through to install his service:

  $ mkdir ~/my-service
  $ emacs ~/my-service/run
  $ chmod 0755 ~/my-service/run

Say the program-idea above is called ``create-service''.  Then

  $ create-service user-x-service-1 ~/my-service

creates a symbolic link

 /service/user-x-service-1 --> /home/x/my-service

The daemontool's svscan program will start the run script within a few
seconds.  From then on, the user can use daemontools to monitor his
service at ~/my-service.

Re: Shepherd user services that run on startup?

[Ben Weinstein-Raun]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

On 12/20/23 16:42, Ben Weinstein-Raun wrote:
> My guess is that this is at least possible, by defining a system-level
> service that starts a shepherd for each user. Would that work?


After struggling with this for a week, I've managed to get a user-level
`shepherd` starting! It fails to actually run, probably due to errors in
my init.scm, but I'm happy with the progress! I still have some fairly
important-feeling questions though:

* When I tried to use `sudo` via the actual package, I get an error
about it needing to be setuid-root. My workaround is to jut directly add
/run/setuid-programs to the PATH, but this is a pretty bad-feeling hack,
as it leaves an unspecified dependency. What's the right way to depend
on sudo? Force the user to pass it in as an argument, maybe?
* I still don't know how to "properly" ensure that the XDG_RUNTIME_DIR
is set, like it should be for a "proper" login shell. Right now, the
shell script just brute-creates the directory where I expec
t it on my
system (and exports that path to the environment). So, if anybody knows:
what's the right way to do this?
* Several times throughout this process, when I had errors in the shell
script that caused it to exit early, my system shepherd became
unresponsive and I had to roll-back, and then reboot using
/proc/sysrq-trigger. This was a little terrifying, since I'm currently
traveling and won't physically see my server again until February. It
was also surprising, since the script is running inside a shepherd
fork-exec constructor, and I'd have thought that this would deal
gracefully with failed starts. Is this a bug in shepherd, or am I
misusing it?

> Anyone have tips on how to go about building this, if so? Especially: 
> What's the easiest way to ensure that a guix service knows the list of 
> users-with-login-shells on the system?


I sidestepped this issue by forcing the user to specify usernames when
instantiating the service. This seems nicer anyway, as m
aybe you don't
want to start a shepherd for every user.

> And, of course, is there a simpler way?

This question still stands!



My code is on github if you're curious:

* service definition is here:
https://github.com/benwr/benwr_guix/blob/main/benwr/services/userherd.scm
* package definition is here:
https://github.com/benwr/benwr_guix/blob/main/benwr/packages/userherd.scm
* shell script is here: https://github.com/benwr/userherd

(This is probably obvious, but just in case: I'd strongly caution
against directly relying on my channel, as I break it constantly)

Thanks in advance for any help!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]