Recently, GNOME announced stronger dependencies on systemd. Mainly userdb and gnome-session.
I’m looking into porting gnome-session to the GNU Shepherd for the Guix System. However, apart from one vague paragraph in the blog post, there is not a lot of guidance available to me. Not even a contact link!
I would like to collaborate with the upstream GNOME contributors on this, and also with the other distros that will have very similar goals as me.
I understand that GNOME wants to rely on stable interfaces instead of old hacky code, but this doesn’t have to be dropping a huge part of the user base! I’m ready to develop and maintain alternatives, but collaboration is key.
Could it be possible to setup a discussion channel, and maybe a guide for non-systemd distros?
Again, I really want to collaborate to bring a nice experience to our users instead of having to come up with hacky solutions on my own.
Have you tried contacting the author of the blog post—who is also a member of the GNOME release team?
I don’t think “a huge part of the user base” is actually running a non-systemd-based distribution, in 2025. You’re, of course, welcome to bring data supporting your statement.
If you want to implement an interface provided by a systemd component, my suggestion is to read the systemd code, and/or ask the systemd authors as well.
I don’t know how Shepherd works, so I can’t really give specific advice. However, you’ll need to replace the following with a Shepherd integration:
the systemd user service unit files. These are spread across all the different packages: localsearch, gnome-settings-daemon, gnome-disk-utility, and of course gnome-session itself
leader-main.c, which currently does some basic environment setup and then asks systemd to start gnome-session-${XDG_SESSION_TYPE}@${SESSION}.target and then handles session shutdown (SIGTERM → tell systemd to stop the service, services stop → quit the leader)
tools/gnome-session-ctl, which is called by various systemd checkpoints to communicate to the service and the leader when things happen
As for userdb, reach out on the systemd mailing list with questions. I’ll be happy to assist there
The Shepherd is great, since it can run as a standalone user daemon. It’s written in Guile, so it can easily be interfaced in C code.
I realized I was rude in my first message, I’m sorry! Thank you so much for being willing to help and your work on gnome-session, it means a lot!
I will be starting the hacking next week, so expect some good activity
Since the Shepherd can run standalone just for gnome-session, do you think it would make sense for me to replace/adapt the builtin startup with a Shepherd one? Of course, I’m willing to maintain it forwards in time.
Void linux, Gentoo, Guix, Artix, Alpine. There are a lot of non systemd distros! Not all of the users will use GNOME of course, but even if its 0.1% of all GNOME users, I still think its a huge part. Because GNOME is for everyone, after all
Since the Shepherd can run standalone just for gnome-session, do you think it would make sense for me to replace/adapt the builtin startup with a Shepherd one? Of course, I’m willing to maintain it forwards in time
It makes sense to do this if your distro is using the Shepherd as its init system and you’re packaging it anyway. As far as I know GUIX is the only one doing this.
Anyway, you can’t really “replace” or “adapt” the builtin startup. Really all that there is to do is remove it completely, then re-implement it. But at that point, I’d rather just stop at removing it, and then leave it be. Put the service management where it belongs: in your system’s service manager. On most systems that’d be systemd --user, and on GUIX that’d be the Shepherd.
In other words: there’s really no need for any service manager to be built into gnome-session.
The Shepherd can run as an init system, but for user services another one is started. Completely standalone!
You’re right, I can see that now that I’ve looked more into the code. I think I will end up with mostly a collection of shepherd services and the replacement for the leader process. I guess I was wondering if the Shepherd leader could be upstreamed, but we can discuss it once I have a cool working fork!
I was wondering if the Shepherd leader could be upstreamed
I would rather not have all the different init systems’ leader processes upstreamed, sorry. If I upstream Shepherd, I’ll have to upstream all the other init systems. And if I upstream the leader, then I’d have to upstream the configuration files as well. That turns into a mess very quickly.
If there are other distros using Shepherd and you’d like to share this configuration between them, you’d also probably want to share the service definitions. Thus, the Shepherd leader + the Shepherd service definitions would belong together in a gnome-session-shepherd package that’s shared somewhere between Shepherd-using distros.
If there’s something you’d like me to do to make the leader smaller (and thus easier to implement), I’d be happy to consider it.
For instance, right now I’m thinking of splitting the leader between the “set environment variables and re-exec in a login shell” part and “talk to systemd” parts. The leader would simply exec from one to the other. Then, theoretically, it’d be possible to make a gnome-session subpackage where the systemd leader (and systemd unit files) are pulled out (call it gnome-session-systemd), conflict it with whatever other init systems’ packages (gnome-session-openrc or the aforementioned gnome-session-shepherd). This would reduce the pain for distros like Gentoo where the user can select their init system, at least.
Also, I want to make it clear that my goals is to make the gnome-session-shepherd usable with any linux distro, no matter the init system. Shepherd is used as a services manager in this case in a separate process.
Sounds like a great idea!
My main worry right now is how I can keep up with the services’ updates if they are in many projects. It would be nice to have a centralized list or something else where I can easily keep up.
Hi everyone! I have a good update for today, my implementation of GNOME session on the shepherd (gnome-session-shepherd) can now successfully boot on Guix!
Adrian, I ended up making a leader to Guile scheme that starts a Shepherd instance for the user, and a collection of shepherd services that act like the systemd services.
Spectacular! Thanks for validating that this works and is possible!
I’ve still yet to separate the session worker between the generic environment handling part and the systemd-specific part. I’m planning on doing that still, if it’s useful to you. Is it useful?
By session worker, do you mean leader-main.c? I’ve made my own version of it in scheme so it wouldn’t impact me, but if you want to have a shared leader and make it easy for me to plug in my initialisation code at the end then I can go back to it!
