GNOME 49 Will Require Deeper systemd Integration

Upcoming GNOME releases will require systemd for key session features, making it harder for non-systemd distros to keep pace without major patches.

GNOME’s relationship with systemd has been debated among Linux users and distributions for years. While the desktop environment hasn’t officially required systemd for core functionality, many of its components have leaned heavily on systemd’s ecosystem, particularly logind, its session management service.

Now, GNOME is taking further steps to deepen its integration with systemd, a move that will make running the desktop on alternative init systems significantly more difficult.

To be clear, GNOME hasn’t been entirely systemd-agnostic for a while. Since 2015, it has relied on logind for session and seat management, dropping support for the older ConsoleKit. However, logind doesn’t have to run under systemd—projects like elogind have allowed GNOME to function on systems running OpenRC, runit, or BSD init.

Still, this compatibility has always been somewhat precarious. Most GNOME developers focus on systemd-based setups, and the project’s automated testing infrastructure doesn’t check non-systemd configurations. As a result, maintaining alternative init support has largely fallen to downstream distributors, often through patches and workarounds.

Okay, what’s changing now? Two major shifts are coming that will strengthen GNOME’s reliance on systemd:

GDM adopts systemd-userdb: The GNOME Display Manager is gaining a dependency on systemd’s userdb, a dynamic user account management system. This change helps modernize GDM’s handling of multi-seat and remote login sessions, replacing what the developers describe as “legacy behaviors and straight-up hacks.”

While a temporary fallback exists for systems without userdb (using static greeter accounts like “gdm-greeter-1,” “gdm-greeter-2,” etc.), this is only a stopgap.

Gnome-session drops its built-in service manager: Since GNOME 3.34, the session manager has used systemd to launch and monitor user services, falling back to an internal service manager only when systemd isn’t available.

That fallback, however, is now being removed. Originally written for GNOME 2.24, the old service manager is considered outdated, poorly maintained, and an obstacle to new features like session save/restore.

What Does This Mean for Non-Systemd Distros?

In short, nothing good. One thing’s for sure: this move by GNOME is bound to stir up heated debate and frustrate both developers and users of systemd-free distributions (Void, Slackware, Alpine, Chimera, Devuan, etc.).

While the path forward isn’t impossible, it’s certainly more complicated. In light of this, the GNOME team suggests a few options:

  • Implement systemd-userdb replacements. Projects like elogind have already filled similar gaps for logind; a similar effort may be needed for userdb.
  • Maintain patches for older GNOME versions. GNOME 48 will continue receiving updates until GNOME 50’s release, giving downstream maintainers time to adapt.

Still, the writing is on the wall: GNOME is moving toward deeper systemd integration, and while alternative setups won’t vanish overnight, they’ll require more effort to keep functional.

For now, non-systemd users still have some breathing room, but as GNOME 50 approaches (around March-April, 2026), the pressure to either adopt systemd or invest in alternative implementations will only grow. Or, of course, you can always just move to a different desktop environment.

For more information, refer to the blog post.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

Leave a Reply

Your email address will not be published. Required fields are marked *