2

Since today when I try to execute systemctl using the root account they fail with a Connection timed out error:

>sudo systemctl
>Failed to list units: Connection timed out

The same thing occurs with systemctl start or systemctl stop when ran as root.

If I try to run the same commands using an user account, I don't get the Connection timed out error (start and stop give the expected error due to lack of permissions in user account).

If I reboot the server, all services that I'm aware of start correctly but I still get the same timeout errors.

PD: Using openSuse 13.2 (Linux version 3.16.7-21-default)

4

Finally I've found the problem.

I figured that process 1 (systemd) was started with --switched-root and --deserialize. And as I found in that link it seems that there are some internal parameters which try to reload some previously saved state.

I've done a kill -9 on process 1 an now the systemd appears without the switched-root and systemctl is working again with or without rebooting.

5
  • I'm also using openSuse 13.2 and have the same problem, but kill -9 doesn't work in my case, as systemd seems to ignore it. Using systemctl daemon-reexec instead restarts it (and is the only systemctl operation that doesn't time out), but with the same parameters, so I keep getting the timeouts afterwards. Any idea how to force it? I can't tell from the link you posted to the other thread if this is strictly required when using initramfs. – Display Name Mar 8 '16 at 22:00
  • 7
    Neither kill -9 1 or systemctl daemon-reexec worked for me so I resorted to the big red switch that is reboot. But that did not work! (Failed to start reboot.target: Failed to activate service 'org.freedesktop.systemd1': timed out. See system logs and 'systemctl status reboot.target' for details. Failed to open /dev/initctl: No such device or address. Failed to talk to init daemon.) After a bit of googling I found systemctl --force --force reboot (ubuntuforums.org/…) did a reboot and appears to be back to normal – northern-bradley Mar 29 '18 at 13:26
  • It worked for me on elementaryOS loki, got stuck after configuring TightVNC server, but now it works like a charm. – ChoCho Sep 24 '18 at 16:28
  • None of all the above worked for me. – Max Jul 26 '19 at 2:27
  • I am getting this issue and it becomes really annoying. Neither kill -9 1 or systemctl daemon-reexec worked. The only solution if found working is the reboot double forced but after 2 days, the problem is back ! – Loenix Sep 9 '20 at 12:26
2

Two alternative solutions to the problem:

1- rebooting with

systemctl --force --force reboot

or

2- without reboot, just moving session files

mv /run/systemd/system/session-*.scope /tmp/
2
  • Warning! systemctl --force --force reboot reboots the server, not just the service! – lepe May 28 '20 at 0:55
  • yes, that is the meaning of reboot. you reboot the server and restart the service. – RASG May 28 '20 at 15:37
0

Another reason you may see this is when systemd is run in virtualized environments. If the different instances of systemd get the same machine id from the filesystem (/etc/machine-id) or from other fallback methods, the system will become unstable and you will see this error when using systemctl or other systemd utils.

I can verify this happens with docker containers which use systemd processes as the entry point. Adding this to help others troubleshoot this obscure error.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.