You are not logged in.
systemd 257.1-1
I am starting to get the following error when running `systemctl --user` commands (any) on one of my headless machines a few seconds/minutes after boot:
❯ systemctl --user daemon-reload
Failed to connect to user scope bus via local transport: Connection refused
This means that I can boot the system, login via SSH and then run some `systemctl --user` command(s) and then after a few seconds or minutes (non-deterministic) I will start to get this error. The system will never recover from this.
Another one of my machines is almost identical but doesn't have this issue. Both systems have the following environment variables:
❯ echo $XDG_RUNTIME_DIR
/run/user/1000
❯ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus
Other than that I checked if any critical systemd service failed but no. I cannot see anything suspicious in the journal.
Since I cannot find this exact error message anywhere on the internet I really hope someone has a hint for me!
Offline
I cannot see anything suspicious in the journal
Probably best to share it here then. Somebody might spot something you've missed.
Para todos todo, para nosotros nada
Offline
Wild guess: AppArmor environment variable scrubbing?
Offline
I did some more testing now and found out that
- NeoVIM is the issue!
- BOTH my machines have this issue
I can reproduce this as follows:
1. Boot
2. Now systemctl --user commands work fine ... until:
3. The moment I open any ~/.config/systemd/user/*.service file using NeoVIM (other editors do not cause any issues, including regular VIM)
These do not show any messages (not even debug) when the issue occurs:
systemctl -t systemd[
systemctl --user -t systemd
I will do some further testing using
- older NeoVIM versions
- NeoVIM without config/plugins
Maybe there is some file lock from a git plugin or whatever
Last edited by CharlieBra7o (2025-01-14 09:53:04)
Offline
I've also been bitten by this same regression. I actually get this with regular VIM, editing from the TTY. I do have the gvim version installed though, which is compiled with a few more options than vanilla vim. FWIW I also tested nano, and this doesn't trigger the bug.
Offline
What triggers this is running the following command:
systemd-analyze --user verify ~/.local/share/systemd/user/<unit>.service
which many linters use for systemd unit files
Offline
Thanks @bretello. I can confirm that this also breaks systemd --user for me. A reboot is necessary to fix it.
Offline
What triggers this is running the following command:
systemd-analyze --user verify ~/.local/share/systemd/user/<unit>.service
which many linters use for systemd unit files
Interesting! Thanks for this insight.
Does this mean that the command systemd-analyze has a bug and it is triggered by one of my NeoVIM plugins?
Offline
I was able to reproduce even without calling `systemd-analyze --user`, so there's something else going on, smells like a pretty bad regression in systemd.
Offline
I seem to be getting the same thing in sway (using sddm) and when trying to log in to the TTY directly.
Funny thing, I ran an upgrade, and the `systemctl --user` commands started working at some point during the upgrade, and they stopped working after the upgrade had completed. Something weird is going on.
Update: when I disable sddm and reboot, and then login from TTY things start to work again.
Last edited by jeremija (2025-01-19 11:52:14)
Offline
I have a related issue, didn't find the problem yet tough
Offline
So I just came across something interesting when working on this problem. If I unset XDG_RUNTIME_DIR, systemctl --user works.
[jeff@kvm-master ~]$ printenv XDG_RUNTIME_DIR
/run/user/1000
[jeff@kvm-master ~]$ systemctl --user
Failed to connect to user scope bus via local transport: Connection refused
[jeff@kvm-master ~]$ unset XDG_RUNTIME_DIR
[jeff@kvm-master ~]$ systemctl --user
UNIT LOAD ACTIVE SUB DESCRIPTION
It seems that systemd can successfully infer the XDG_RUNTIME_DIR if it's not in the environment. I wonder if something gets funky with the /run/user/1000 directory. Will continue troubleshooting, but thought I should report this finding.
Quick edit: running
systemctl --user daemon-reexec
from a session without XDG_RUNTIME_DIR set seems to fix it for sessions that do have XDG_RUNTIME_DIR set. Much better than a hard reboot!
Last edited by cookiecaper (2025-01-29 04:26:50)
Offline
ran into this today as well. Although im on debian testing, this thread is what google provided me so ill share what I found and what my fix was. It might help arch users, and it might help other lost debian souls.
when I checked what was in my XDG_RUNTIME_DIR
$ printenv XDG_RUNTIME_DIR
/run/user/1000
I noticed that it did not match the permissions set in here:
$ ls -al /run/user/
total 0
drwxr-xr-x 4 root root 80 Jan 31 22:58 .
drwxr-xr-x 29 root root 840 Jan 31 22:58 ..
drwx------ 4 firstuser firstuser 120 Jan 31 22:58 1000
drwx------ 4 targetuser targetuser 120 Jan 31 22:55 1001
since the permission of the dir set in XDG_RUNTIME_DIR was for the wrong user, I just run this to fix it
export XDG_RUNTIME_DIR=/run/user/1001
Last edited by RetroZelda (2025-02-01 04:19:21)
Offline
Thanks for posting @RetroZelda. Much appreciated. Sorry, are you saying that your logged in user is targetuser?
FWIW when I run your commands, /run/user/1000 (i.e. /run/user/1000) is indeed owned by my logged in user.
Offline