Systemd user service doesn't start at login

JoeHartley · 2025-09-21 17:01:30

I recently updated my system, and afterwards pipewire did not start for me. After hours of troubleshooting, I find that the issue is that the systemd user service is not running after a system boot.

$ systemctl status user@101.service
○ user@101.service - User Manager for UID 101
     Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
    Drop-In: /usr/lib/systemd/system/user@.service.d
             └─10-login-barrier.conf
     Active: inactive (dead)
       Docs: man:user@.service(5)

Once I restart it, pipewire runs again and I have sound:

[jh@xtc ~]$ sudo systemctl restart user@101.service

[jh@xtc ~]$ systemctl status user@101.service
● user@101.service - User Manager for UID 101
     Loaded: loaded (/usr/lib/systemd/system/user@.service; static)
    Drop-In: /usr/lib/systemd/system/user@.service.d
             └─10-login-barrier.conf
     Active: active (running) since Sun 2025-09-21 12:49:53 EDT; 1s ago
 Invocation: 581e335f4ad84171837a1ae262215ae0
       Docs: man:user@.service(5)
   Main PID: 2471 (systemd)
     Status: "Ready."
      Tasks: 14
     Memory: 40.2M (peak: 40.7M)
        CPU: 1.181s
     CGroup: /user.slice/user-101.slice/user@101.service
             ├─init.scope
             │ ├─2471 /usr/lib/systemd/systemd --user
             │ └─2474 "(sd-pam)"
             └─session.slice
               ├─dbus-broker.service
               │ ├─2483 /usr/bin/dbus-broker-launch --scope user
               │ └─2484 dbus-broker --log 11 --controller 10 --machine-id fd5de>
               ├─pipewire.service
               │ └─2485 /usr/bin/pipewire
               └─wireplumber.service

I can work around this by restarting the service once I boot, or by putting the restart in ~/.bash_profile, but I'd really like to figure out why this isn't starting as it used to. Thanks!

loqs · 2025-09-21 17:58:38

You could try using the ALA to determine which package update triggered the issue. Why are you logging in as a system user or do you have a normal user with the UID 101? Have you checked the journal for possible clues?

Last edited by loqs (2025-09-21 17:59:09)

JoeHartley · 2025-09-22 12:38:55

loqs wrote:

You could try using the ALA to determine which package update triggered the issue. Why are you logging in as a system user or do you have a normal user with the UID 101? Have you checked the journal for possible clues?

I'll try and determine the package but I don't feel the need to downgrade as there's a workaround.

As for UID 101, that's a holdover from earlier days when 100 and below was reserved for system accounts. This Arch installation is from 10 years ago (Mar 6 2015 according to pacman.log!) and my account was recreated from an even older Fedora machine where I had the 101 UID.

seth · 2025-09-22 14:23:54

Does this affect UIDs w/ non-system values (create a test user)
https://bbs.archlinux.org/viewtopic.php … 3#p2262583

I don't feel the need to downgrade as there's a workaround

The point is to figure what has triggered this, see https://bbs.archlinux.org/viewtopic.php?id=308380

rapidcow · 2025-12-03 05:39:12

I am in a similar situation (though my UID being below 1000 is entirely artificial ) and I took a look at this - it appears (as of systemd v258) that what systemd regards as "system user" is defined at compiled-time* by something called SYSTEM_UID_MAX - not by reading something configurable like /etc/login.defs**. According to UIDS-GIDS.md (which I found in a related issue), you can check this by running pkg-config(1):

pkg-config --variable=systemuidmax systemd

If it shows 999 (or anything that is not strictly less than your UID 101), then that may be the cause of it.

You may try re-compiling systemd from source with makepkg, since the systemd from the official Arch repositories configures SYSTEM_UID_MAX it to 999. Meson honored my /etc/login.defs when I changed my SYS_UID_MAX there†, and I think it should honor yours too. (You can also try appending to the _meson_options array with something like "-Dsystem-uid-max=99", but I haven't tried that so I can only hope it works...)

---
*Tracing backwards from where the user service is started - a user@UID.service is started only if there is a session under that UID that wants service manager. On login, a session is created by pam_systemd.so via dbus. Its session class is determined by user_record_disposition(), which in particular calls uid_is_system() to determine if it is a system user below the minimum user UID, which is controlled by SYSTEM_UID_MAX which is defined by Meson at compile-time. I am not involved in systemd though, so take my words with a grain of salt... :x

†It seems to probe /etc/login.defs for the system defaults using this awk script.

**It might be possible to compile with -DENABLE_COMPAT_MUTABLE_UID_BOUNDARIES (since 2020-09-25), so that /etc/login.defs is used instead whenever possible.

Last edited by rapidcow (2025-12-03 06:03:15)

loqs · 2025-12-03 07:00:13

@rapidcow what about system users in the range 101-999 such as those dynamically created by systemd-sysusers without a fixed UID or any with a fixed UID of 100 and above? Is this not potentially trading one problem for another? As an aside fix system group addition (FS#16092) FS#16092 - [shadow] groupadd always add system groups with gid=99 is from 2010.

Last edited by loqs (2025-12-03 07:01:41)

Arch Linux

#1 2025-09-21 17:01:30

Systemd user service doesn't start at login

#2 2025-09-21 17:58:38

Re: Systemd user service doesn't start at login

#3 2025-09-22 12:38:55

Re: Systemd user service doesn't start at login

#4 2025-09-22 14:23:54

Re: Systemd user service doesn't start at login

#5 2025-12-03 05:39:12

Re: Systemd user service doesn't start at login

#6 2025-12-03 07:00:13

Re: Systemd user service doesn't start at login

Board footer