Systemd service takes 584542y 2w 2d 20h 1min 49.255s to become active

… or started. How come? How is it to be interpreted?

$ systemd-analyze critical-chain

The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character. @4.468s
└─gdm.service @4.447s +20ms
  └─systemd-user-sessions.service @4.428s +16ms
    └─ @4.413s
      └─NetworkManager.service @3.953s +459ms
        └─ @3.952s
          └─dbus-broker.service @3.929s +21ms
            └─dbus.socket @3.908s
              └─ @3.907s
                └─systemd-timesyncd.service @3.832s +74ms
                  └─systemd-tmpfiles-setup.service @3.018s +74ms
                    └─systemd-journal-flush.service @926ms +1.882s
                      └─systemd-remount-fs.service @710ms +197ms
                        └─systemd-fsck-root.service @584542y 2w 2d 20h 1min 49.255s +17ms

systemd-fsck-root.service @584542y 2w 2d 20h 1min 49.255s +17ms

such a precise date in the (not very near) future !
I guess :space_invader: or 11 secretos de #BackToTheFuture que ca… is trying to tell you something

The systemd-journal.socket was activated. A bit over 584,542 years later, the systemd-fsck-root.service was started. It took 17 milliseconds.


It would be sad if that was just a bug,

because I’m so ready


I guess I may be considering a cryopreservation solution to wake up in the future.

Hopefully by then systemd has finished its job.

1 Like

Max 64 bit integer in microseconds is a bit more than 584542 years…
At least you shouldn’t have to wait any further :slight_smile:

1 Like

Good to know, I can live with that :rofl:

1 Like