Hi,

this is a known problem in GuixSD (not in shepherd) and I don't think anyone fixed
it yet, because it requires some design (and is kinda harder than ignoring the
problem and letting the user choose - see below).

There is only rudimentary support for distinguishing sessions from users in GuixSD
(I guess nowadays everyone is using a computer of their own and people don't
remember huge shared computers which you would dial into multiple times from
different sites (not necessarily after hanging up the previous connection) -
I work with the latter daily so I do remember).

Shepherd assumes to be run per user (for non-root), not per session.
For the vast majority of tasks-to-be-automated, that is what you want.

But who starts the per-user shepherd?

Right now, nobody.

I manually edited my session startup file (in my case ~/.fluxbox/startup) to
invoke "shepherd" and expect it to error on subsequent sessions except for the
first one for this user - so only one shepherd per user will actually stay running.

This is a simple way to do it and I prefer it to any more complicated solutions -
since it's in the unix spirit of "worse is better" (in this case: non-sarcastic).

(For a more universal (non-fluxbox, it's too old) way, use ~/.config/autostart
and put a "shepherd.desktop" file there)

This assumes that nobody will clean up session processes when the session ends,
otherwise it will do the wrong thing (i.e. kill the per-user shepherd even though
other sessions of that user still need it).

The assumption is justified because of the following:

The right design overall for the system would be to clean up USER processes
when all sessions of that user ended (this is not the default for elogind, but
it could be enabled by the logind.conf option "KillUserProcesses").  (This
would break Screen if not started right away with the session, though)
In any case, the "simple way" above works when KillUserProcesses=no and
also when KillUserProcesses=yes, so for me problem solved ;P

(Also, traditionally UNIX would kill the controlling (that is, first) process
that was started in a terminal once that terminal is disconnected (kill via
sending that controlling process SIGHUP).
I don't think that that is a problem here since that controlling process is
usually the shell, not shepherd).

There are multiple other ways to handle starting the per-user shepherd, but
they are kinda complicated and all require new GuixSD services:

* One way would be to monitor /run/user (see elogind for why), wait until a new
subdirectory appears, and then launch the per-user shepherd (as that user,
of course).  (In the end we have a race between our new service running the
per-user shepherd and our user logging out.  So also wait until a subdirectory
disappears and kill the corresponding per-user shepherd - if it's still there :P)

A very easy implementation (but not very abstract) would simply hard-code the
above use case.

A more sophisticated implementation would provide a file-monitoring service
extension which would allow users to monitor arbitrary files and call a
procedure once they change (using inotify, fanotify (and stat - because
inotify can overflow, and then you have to scan manually) under the hood).

* Another way would be to listen to the signal that elogind sends when a user
logs in or out, which is (see elogind):

        return sd_bus_emit_signal(
                        u->manager->bus,
                        "/org/freedesktop/login1",
                        "org.freedesktop.login1.Manager",
                        new_user ? "UserNew" : "UserRemoved",
                        "uo", (uint32_t) u->uid, p);

(In my opinion the signal names are misnomers - sounds like accounts are created
resp. deleted, which is not the case O_o)
(In the end we have a race between our new service running the per-user
shepherd and our user logging out.  So also wait until UserRemoved is
emitted and kill the corresponding shepherd :P)

* Another way would be to use pam's pam_exec for "account" to start shepherd
(make sure to switch to the user account first).  Race...

* In the end, all this is special-casing containerization and I wonder
whether it would be better to have an option for guix environment -C
which starts a shepherd.  Older UNIXes just abused user accounts
as good-enough containerization, but that's kinda outdated anyway.

Also, are there user accounts (system user accounts, root etc) which don't
need a user-specific shepherd?  How to specify those?

As you can see, that's quite a can of worms - and I would prefer it not
to default to any of those and have the user choose which way (if any) to
invoke his shepherd.  This keeps complexity down.  (We can document it in
the manual)
But can't hurt to have the *abilities* above.

What do you think?