0

I'm facing this error causing a 25 second timeout on every login. I've searched and attempted multiple suggested troubleshooting steps, but none have resolved the issue:

The error:

Nov 06 12:57:03 phantom dbus-daemon[1718]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) 

The symptoms are a 25s timeout on every new login or sudo.

What I've tried:

This ubuntu bug suggests increasing verbosity via systemctl log-level debug. I then monitored logs via journalctl -b -f while reproducing the issue, but I couldn't find any new meaningful logs:

06 13:03:04 phantom sshd[2525474]: pam_afs_session(sshd:setcred): pam_sm_setcred: entry (establish) Nov 06 13:03:04 phantom sshd[2525474]: pam_afs_session(sshd:setcred): skipping tokens, no Kerberos ticket cache Nov 06 13:03:04 phantom sshd[2525474]: pam_afs_session(sshd:setcred): pam_sm_setcred: exit (success) Nov 06 13:03:04 phantom sshd[2525474]: pam_unix(sshd:session): session opened for user pixel8(uid=1003) by (uid=0) (start big time gap...) ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[ A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[ [A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^ [[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[ A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[ [A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^ [[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[ [A (end big time gap...) Nov 06 13:03:19 phantom dbus-da emon[1718]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) Nov 06 13:03:19 phantom systemd-logind[1731]: Failed to start user service '[email protected]', ignoring: Failed to activate service 'org.freedesktop.systemd1': timed out (ser vice_start_timeout=25000ms) Nov 06 13:03:44 phantom dbus-daemon[1718]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) Nov 06 13:03:44 phantom systemd-logind[1731]: Failed to start session scope session-4291.scope: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start _timeout=25000ms) Nov 06 13:03:44 phantom sshd[2525474]: pam_systemd(sshd:session): Failed to create session: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_tim eout=25000ms) 

I tried checking org.freedesktop.systemd1 in busctl according to this post, it shows as "activateable", therefore inactive:

$ busctl NAME PID PROCESS USER CONNECTION UNIT SESSION DESCRIPTION :1.0 1732 systemd-machine root :1.0 systemd-machined.service - - :1.1 1731 systemd-logind root :1.1 systemd-logind.service - - :1.11 1816 ModemManager root :1.11 ModemManager.service - - :1.144651 463480 xdg-desktop-por ealfonso :1.144651 session-2.scope 2 - :1.144652 463460 xdg-desktop-por ealfonso :1.144652 session-2.scope 2 - :1.144653 463516 gnome-keyring-d ealfonso :1.144653 session-2.scope 2 - :1.146106 561239 pipewire ealfonso :1.146106 [email protected] - - :1.146107 561246 wireplumber ealfonso :1.146107 [email protected] - - :1.15 1994 upowerd root :1.15 upower.service - - :1.150973 854735 emacs ealfonso :1.150973 session-2.scope 2 - :1.151258 886628 emacs ealfonso :1.151258 session-2.scope 2 - :1.156303 3181508 zathura ealfonso :1.156303 session-2.scope 2 - :1.156389 1384977 wpa_supplicant root :1.156389 wpa_supplicant.service - - :1.156448 1391442 udisksd root :1.156448 udisks2.service - - :1.156461 1392279 snapd root :1.156461 snapd.service - - :1.163808 1989241 emacs ealfonso :1.163808 session-2.scope 2 - :1.164285 2035313 emacs ealfonso :1.164285 session-2.scope 2 - :1.176600 3022601 ipp-usb root :1.176600 ipp-usb.service - - :1.18 2231 colord colord :1.18 colord.service - - :1.181 9804 systemd ealfonso :1.181 [email protected] - - :1.183 9824 pipewire-pulse ealfonso :1.183 [email protected] - - :1.185 9850 rtkit-daemon root :1.185 rtkit-daemon.service - - :1.19 2184 unattended-upgr root :1.19 unattended-upgrades.service - - :1.2 1716 bluetoothd root :1.2 bluetooth.service - - :1.240262 4122447 cupsd root :1.240262 cups.service - - :1.240263 4122454 cups-browsed root :1.240263 cups-browsed.service - - :1.240264 4122454 cups-browsed root :1.240264 cups-browsed.service - - :1.240267 4122459 dbus lp :1.240267 cups.service - - :1.24486 2097026 gnome-keyring-d ealfonso :1.24486 [email protected] - - :1.248447 660771 chromium ealfonso :1.248447 session-2.scope 2 - :1.264308 2527572 systemctl root :1.264308 session-2.scope 2 - :1.264312 2527676 busctl ealfonso :1.264312 session-2.scope 2 - :1.3 1715 avahi-daemon avahi :1.3 avahi-daemon.service - - :1.4 1724 polkitd polkitd :1.4 polkit.service - - :1.47641 4185567 Xorg root :1.47641 session-2.scope 2 - :1.48198 43832 emacs ealfonso :1.48198 session-2.scope 2 - :1.5 1727 power-profiles- root :1.5 power-profiles-daemon.service - - :1.566 36827 gvfs-udisks2-vo ealfonso :1.566 [email protected] - - :1.570 36909 gvfsd-dnssd ealfonso :1.570 [email protected] - - :1.6 1713 accounts-daemon root :1.6 accounts-daemon.service - - :1.83445 3315371 emacs ealfonso :1.83445 session-2.scope 2 - com.ubuntu.SoftwareProperties - - - (activatable) - - - fi.w1.wpa_supplicant1 1384977 wpa_supplicant root :1.156389 wpa_supplicant.service - - net.hadess.PowerProfiles 1727 power-profiles- root :1.5 power-profiles-daemon.service - - org.bluez 1716 bluetoothd root :1.2 bluetooth.service - - org.freedesktop.Accounts 1713 accounts-daemon root :1.6 accounts-daemon.service - - org.freedesktop.Avahi 1715 avahi-daemon avahi :1.3 avahi-daemon.service - - org.freedesktop.ColorManager 2231 colord colord :1.18 colord.service - - org.freedesktop.DBus 1 systemd root - init.scope - - org.freedesktop.GeoClue2 - - - (activatable) - - - org.freedesktop.ModemManager1 1816 ModemManager root :1.11 ModemManager.service - - org.freedesktop.PackageKit - - - (activatable) - - - org.freedesktop.PolicyKit1 1724 polkitd polkitd :1.4 polkit.service - - org.freedesktop.RealtimeKit1 9850 rtkit-daemon root :1.185 rtkit-daemon.service - - org.freedesktop.UDisks2 1391442 udisksd root :1.156448 udisks2.service - - org.freedesktop.UPower 1994 upowerd root :1.15 upower.service - - org.freedesktop.hostname1 - - - (activatable) - - - org.freedesktop.import1 - - - (activatable) - - - org.freedesktop.locale1 - - - (activatable) - - - org.freedesktop.login1 1731 systemd-logind root :1.1 systemd-logind.service - - org.freedesktop.machine1 1732 systemd-machine root :1.0 systemd-machined.service - - org.freedesktop.network1 - - - (activatable) - - - org.freedesktop.nm_dispatcher - - - (activatable) - - - org.freedesktop.nm_priv_helper - - - (activatable) - - - org.freedesktop.portable1 - - - (activatable) - - - org.freedesktop.realmd - - - (activatable) - - - org.freedesktop.systemd1 - - - (activatable) - - - org.freedesktop.timedate1 - - - (activatable) - - - org.libvirt - - - (activatable) - - - org.opensuse.CupsPkHelper.Mechanism - - - (activatable) - - - 

The top answer suggests calling systemctl daemon-reexec or sudo kill 1. I tried both but the service was still in the same activatable state according to busctl.

The top answer suggests checking ram, I seem to have plenty:

$ free -h total used free shared buff/cache available Mem: 62Gi 24Gi 17Gi 1.2Gi 22Gi 37Gi Swap: 10Gi 3.9Gi 7.0Gi 
$ busctl tree org.freedesktop.systemd1 Failed to introspect object / of service org.freedesktop.systemd1: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) No objects discovered. 

The answer in this post suggests checking for disk usage, but my disks are not full:

█[phantom][130]$ df | grep -v loop df: /tmp/.mount_CrealiATmbee: Transport endpoint is not connected df: /tmp/.mount_CrealiagiqZi: Transport endpoint is not connected Filesystem 1K-blocks Used Available Use% Mounted on udev 32785700 0 32785700 0% /dev tmpfs 6566180 2912 6563268 1% /run /dev/mapper/phantom--vg-root 227625420 176817524 39172392 82% / tmpfs 32830896 966540 31864356 3% /dev/shm tmpfs 5120 16 5104 1% /run/lock /dev/sda2 466026 283815 157226 65% /boot /dev/sda1 523244 5984 517260 2% /boot/efi AFS 2147483647 0 2147483647 0% /afs tmpfs 6566176 108 6566068 1% /run/user/1000 /dev/sdb1 479600448 62969472 392195316 14% /disk2 █[phantom][0]$ 

Other posts suggest checking the output of sudo systemctl status -l dbus-org.freedesktop.login1.service, it is the same as above.

sudo systemctl status -l dbus-org.freedesktop.login1.service Failed to get properties: Failed to activate service 'org.freedesktop.systemd1': timed out (service_star> 

Other posts suggests upgrading the system and the dbus package, but the problem persisted after the upgrade.

Yet another post suggests restarting the systemd-logind, but this fails for me:

$ sudo systemctl restart systemd-logind Failed to restart systemd-logind.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms) See system logs and 'systemctl status systemd-logind.service' for details. █[phantom][1]$ sudo systemctl status systemd-logind.service 

The Google AI answer suggests that there may be too many sessions, but I only seem to have one session according to loginctl:

$ sudo loginctl list-sessions SESSION UID USER SEAT TTY 2 1000 ealfonso seat0 tty2 1 sessions listed. 

How can I find out the real reason this org.freedesktop.systemd1 service is timing out? Since I'm able to log in normally after the timeout, is the service really needed? If not, how can it be disabled?

I noticed these interesting error messages that were being logged in a terminal window. One such message says systemd[1]: Freezing execution, which seems to indicate that process 1 froze itself to avoid crashing, as grawity's answer explains:

█[phantom][~][0]$ Message from syslogd@phantom at Nov 3 14:12:59 ... kernel:[1830586.685525] systemd[1]: segfault at c ip 00007f6e190a3d89 sp 00007ffcdf3693a0 error 4 in libsystemd-core-252.so[7f6e18fce000+e5000] likely on CPU 6 (core 12, socket 0) Message from syslogd@phantom at Nov 3 14:12:59 ... kernel:[1830586.685545] Code: 48 8d 35 a6 e6 04 00 48 8d 3d 55 08 05 00 e8 be d9 f2 ff e8 59 ea f2 ff 66 0f 1f 84 00 00 00 00 00 53 48 85 ff 74 6a 48 89 fb <48> 8b 7f 08 48 85 ff 74 36 e8 99 b9 f2 ff 48 8b 43 10 48 8b 53 08 Broadcast message from systemd-journald@phantom (Mon 2025-11-03 14:12:59 EST): systemd[1]: Caught <SEGV> from PID 12. Message from syslogd@phantom at Nov 3 14:12:59 ... systemd[1]: Caught <SEGV> from PID 12. Broadcast message from systemd-journald@phantom (Mon 2025-11-03 14:12:59 EST): systemd[1]: Caught <SEGV>, dumped core as pid 497578. Message from syslogd@phantom at Nov 3 14:12:59 ... systemd[1]: Caught <SEGV>, dumped core as pid 497578. Broadcast message from systemd-journald@phantom (Mon 2025-11-03 14:12:59 EST): systemd[1]: Freezing execution. Message from syslogd@phantom at Nov 3 14:12:59 ... systemd[1]: Freezing execution. █[phantom][~][0]$ 
6
  • What is process 12 (ps 12) if you have not yet rebooted? Is it a [kworker] of some kind or is it a user space process? At first glance it seems a bit odd for SIGSEGV to have a sender PID.. Commented Nov 10 at 5:02
  • I did reboot, and the problem keeps happening. Looking at journalctl -b logs, around first occurrence of "freezing" I see systemd[1]: Reloading., systemd[1]: Caught <ABRT> from our own process., Caught <ABRT>, dumped core as pid 420191. Freezing execution. I tried to look for the core dump under /var/lib/systemd/coredump/ but it is empty. I tried installing the systemd-coredump package, but I'm not sure that it succeeded. How can I find the systemd core dump? Commented Nov 10 at 12:51
  • 1
    If systemd-coredump is installed, then coredumpctl is the primary tool. But check sysctl kernel.core_pattern to verify that coredumps were actually redirected to systemd-coredump. If they were not, then kernel.core_pattern will show where they get dumped directly. The crashing program has no control over it; /var/lib/systemd is just "where systemd-coredump gathers all dumps", not "where systemd puts its own dumps". Commented Nov 10 at 13:27
  • 1
    SIGABRT upon reload would generally indicate a bug within systemd that its own internal checks caught – I can't remember any off the top of my head if there were any similar bugs, it will depend on which systemd version you have. (If it's an older version, then report it to the distribution so that they could find and backport any patches.) The SIGSEGV on the other hand seems like a different issue. Commented Nov 10 at 13:33
  • coredumpctl list Failed to check if any [email protected] units are running: Connection timed out No coredumps found. I did find /lib/systemd/systemd-coredump, but how do I analyze it? Everything points to coredumpctl but it doesn't list any coredumps. Is there a gdb command line I can use to inspect this core dump? I'd like to add some details if I am to make a bug report. Commented Nov 10 at 13:41

1 Answer 1

1

Since I'm able to log in normally after the timeout, is the service really needed?

Kind of.

org.freedesktop.systemd1 is literally systemd – not one of its additional components but the actual 'init system' process i.e. PID 1 i.e. the system's service manager. It is used for a few more things beyond just handling your login.

Talking to systemd isn't strictly necessary for user login, although generally useful due to the way services work in systemd:

  • Every service process belongs to its 'cgroup' (control group) and every child process spawned by that service also belongs to the same cgroup.

    So when you log in via console, you're in the cgroup of [email protected], and when you log in via SSH you're in the sshd.service cgroup. Now if someone were to restart sshd.service, that would kill all processes in that cgroup – including all users' shell sessions.

    Systemd-logind handles this by being called at login time (through a PAM module) to move each user's process into a dedicated 'session' cgroup, e.g. session-5.scope, thus "detaching" your session's lifetime from the service. Root can SSH into the server, do 'systemctl restart sshd', and all sessions will carry on (as the bash processes and the sshd worker processes are part of the user session now, not part of the service).

  • There are a few more things that "creating a systemd-logind session" triggers. For example, a dedicated service manager is started for that user – again, not strictly necessary (we lived without it for years), but it's something that various desktop environments have come to expect. GNOME won't run without the systemd --user process these days.

How can I find out the real reason this org.freedesktop.systemd1 service is timing out?

As previously mentioned, this service represents 'init' aka PID 1 – which makes it a bit of an exception to the usual "bus activation" process.

~

Normally, bus activation works by having the D-Bus daemon process (dbus-daemon or dbus-broker) look for the service in /usr/share/dbus-1/system-services/.

  • In the systemd world, dbus-daemon looks at the SystemdService= parameter and contacts systemd to start the respective service.

  • If that parameter doesn't exist, then dbus-daemon looks at the Exec= parameter and directly spawns that process within dbus.service (the traditional way). Note that 'dbus-broker' does not do this; it uses systemd exclusively.

  • (Yes, the D-Bus files end with .service – don't confuse them with systemd .service files! The term 'service' is not systemd-exclusive, these are both different yet overlapping kinds of "services".)

So the usual troubleshooting steps would be 1) look at dbus.service logs to see if it reports any spawn/exec failures, 2) try to run the respective Exec manually as root (there's no magic in bus activation, in the end the binary itself is responsible for connecting to the bus, so it can just as well be started upfront).

But the service in question is systemd. So "contacts systemd to start the respective service" can't really be done, because systemd itself is not a systemd service. And there is no Exec= because systemd is always already running – it's what started dbus-daemon! – indeed the respective D-Bus config file only has Exec=/bin/false.

So the name isn't really supposed to be "activatable" – don't ask me why there even is a .service file claiming that it ought to be; I don't remember.

Instead, systemd always connects to D-Bus proactively, much like any other "always-on," non-activatable service (with the exception that systemd is the parent here so it has specific code to wait until dbus.service has started and only then attempt the bus connection). As far as regular programs are concerned, org.freedesktop.systemd1 is always present, like any other non-activatable D-Bus service that got started on boot.

~

If systemd is not on the bus, given that it is the init system process, the most likely problem is that it has crashed. Init tries hard to not 'crash' – if the init process exits, you immediately get a kernel panic – so systemd deliberately freezes in such situations. Usually you will get some systemd messages in dmesg saying something along those lines. I'd also check journalctl -b (all combined logs from current boot).

There is a possibility that systemd disconnected for some other reason, in which case sending SIGUSR1 will ask it to try connecting again. SIGUSR1 is kill -USR1 1. (By default, the 'kill' command sends a SIGTERM, which systemd treats as a "reexec" request.) But that won't work in a crashed state.

One important thing to note is that org.freedesktop.systemd1 is not the only control interface that systemd has. When you do systemctl as root it first attempts to use a direct (peer-to-peer) D-Bus socket that is handled by pid1 itself, and only failing that attempts to go through the system bus. (This direct socket allows systemd to work without dbus-daemon.)

So if D-Bus activation were the problem, you would still at least be able to use sudo systemctl through the direct socket. The fact that you aren't suggests that the service manager is completely dead – your best option might be to give dmesg a look, then manually kill stuff like database services for a clean exit, then do sync and hard-reboot. (You can do reboot -ff or echo b > /proc/sysrq-trigger to force a hard reboot.)

2
  • thanks for the detailed answer. I noticed some serious-looking errors being presented in one of my open terminals, including "systemd[1]: Freezing execution", this was on Nov 3 so several days ago. I am curious to find out what caused the freeze before attempting to reboot, but looking at dmesg logs doesn't show anything interesting. Commented Nov 8 at 0:17
  • 1
    Check the other logs (journalctl -b) then. Commented Nov 8 at 11:24

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.