Hello,
I am just ordinary user of guix, shepherd,
I never contributed to shepherd,
but I still think I can answer some of your questions
or explain design:
> Hi,
> How does my user ("dannym")'s shepherd (and user dbus--probably by
> shepherd?) get started? (I'm using guix home--if it's important)
It is important. User shepherd is configured by guix home,
so unless you configured services yourself in some
other way, shepherd wouldn't do anything if you started
it without having guix home.
Guix home is also what ensures it starts.
Specifically, guix home has a guile script that is executed from
~/.profile (which should be executed by your shell's profile script).
This script ensures only one shepherd is started by making a file
$XDG_RUNTIME_DIR/on-first-login-executed.
> I ask because I just had to debug a race with deadlock of two dannym
> shepherds (one of them was me starting it in
> ~/.config/autostart/shepherd.desktop same like I have been doing the
> last few years[1]) fighting over pipewire and wireplumber, deadlocking
> very very often--which was not fun. (at some point I was debugging the
> kernel :P)
I don't think you should start home's shepherd
yourself like that when you are using guix home. You should rather rely
on the ~/.profile scripts. If you aren't, you should at least execute
~/.guix-home/on-first-login to handle race conditions.
> let's please avoid breaking backward compat like this. Also, why could
> I even start two shepherds at the same time? Did someone remove the
> check?
Running only once per seat is ensured by guix home's scripts.
I am pretty sure this check has not been in shepherd at least
for more than half a year. But anything more for, I cannot
account for. Did you mean that it was like that many months / few years ago,
not just changed recently?
> Maybe a small overview of what terms mean in elogind:
> - USER means a user account like "dannym".
> - SESSION means a logged-in instance of a user account "dannym".
> There can be any number of sessions per user (logged in at the same
> time!), or 0.
> - SEAT means one specific pair of keyboard, mouse and screen assigned to
> a fixed physical location.
> There can be any number of current sessions (and thus, implicitly,
> users) per seat, or 0.
> It seems that the directory /run/user/1000 exists once per user (uid
> 1000 in this case).
Yes, exactly.
> Since the user shepherd creates /run/user/1000/shepherd/socket, that
> means we assume there's one shepherd per user (NOT per session).
> In my opinion that makes sense for timers (and maybe log rotation),
> ssh-agent. Not sure about pipewire (maybe?).
This means that the same sound from pipewire works anywhere, you play something
in DE and you can listen to it even from tty when you're logged in as same user.
Note that even the most common system init - systemd, does this. It manages
one bus per user seat. And that goes for all user services on systemd.
Shepherd is more flexible in this regard that it's possible to run
multiple shepherd's under one user by utilizing the --socket flag.
This is not to say that it's the correct way, but that it's a common
way and guix-home isn't doing something out of the ordinary here.
I agree more flexibility could be pleasant in this regard but I am
not sure if the complexity will be paid off, since I think
not many users use multiple sessions where they would expect
seamless work on both sessions. (ie. it can currently happen
that a file dialog will open in the other session if you're using
xdg desktop portals gtk for file chooser)
> Likewise, since the user dbus uses /run/user/1000/bus , it is one dbus
> instance per USER, not session.
> If you want a session dbus, that's something you can do--but then you
> have to forward dbus messages between user dbus and session dbus (the
> latter you have to start manually with a random socket, NOT with
> /run/user/1000/bus).
> Let's keep that in mind when designing services.
Guix home runs dbus through shepherd. There is currently just one
instance of shepherd per seat ran by guix home. So currently it's
not easy to do multiple dbus sockets from a guix home. It would
require serious redesign.
> If we don't have tests for that, we should totally add tests where two
> sessions of the same user are opened (without closing in-between) and
> then one is closed and then the remaining session used.
> Note: elogind has a "rm -rf /run/user/1000" that runs after
> UserStopDelaySec after all that user's sessions ended[2].
> Note: elogind-configuration's "kill-user-processes?" actually kills all
> that user's processes OF THAT CGROUP on SESSION exit. What cgroup do we
> use in guix home? Which one for the user shepherd?
I don't know much about cgroups, but as I said they are ran
from ~/.profile, so it means it is ran by the login shell
upon user session start.
I don't think this is taken care of anyhow,
I am not sure if even can be - can the user session decide this,
or does it have to be decided from root that would have to fork
the process and reown the process to user?
Guix home isn't really a running process except for the shepherd
it uses for services. So I don't think the part of question for
guix home makes sense here. Guix home scripts for environment
setup will be ran on every login, and will be finished rather quickly,
they just give you the environment.
> [1] shepherd has (had?) a check whether the socket was already there and
> if so, it would (correctly) NOT remove it and then (correctly) would
> fail startup. That way, there's only at most be one shepherd running
> per user (not per session).
> [2] elogind source has: "#if 0 /// elogind does not start a user service
> manager, the delay is unneeded."
> elogind not starting a user (not session) service manager seems
> ill-advised.
I don't know about this functionality in elogind. But if it exists,
I don't think guix home can just use it. Guix home is designed to run
on systems even without elogind by its simplicity of using just
the user's profile scripts for startup.
The only thing you have to ensure without elogind
is to get an XDG_RUNTIME_DIR you set yourself and create yourself.
Message-ID: <87frjg3ubu....@ditigal.xyz>
