5

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)

Improve this question

3 Answers 3

Reset to default
5

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.

Improve this answer
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, 2016 at 22:00
  • 8
    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, 2018 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, 2018 at 16:28
  • None of all the above worked for me.
    – Max S.
    Jul 26, 2019 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, 2020 at 12:26
5

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/
Improve this answer
3
  • 1
    Warning! systemctl --force --force reboot reboots the server, not just the service!
    – lepe
    May 28, 2020 at 0:55
  • yes, that is the meaning of reboot. you reboot the server and restart the service.
    – RASG
    May 28, 2020 at 15:37
  • 1
    Option #1 solved my problem.
    – Pino
    Jun 16, 2023 at 8:16
2

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .