Systemd-analyze showing error

Hello everyone, so this is fresh installation with kde desktop.
I got this error when trying to check systemd-analyze:

Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use ‘systemctl list-jobs’ to see active jobs

and with systemctl list-jobs i got this:
systemctl list-jobs

JOB UNIT TYPE STATE
2 multi-user.target start waiting
91 man-db.timer start waiting
69 logrotate.timer start waiting
83 updatedb.timer start waiting
32 systemd-time-wait-sync.service start running
33 time-sync.target start waiting
66 timers.target start waiting
1 graphical.target start waiting
68 shadow.timer start waiting

I dont think it should be that way, any idea what is wrong?

No it shouldn’t be that way but for the moment there is no need in worrying about it.

I installed KDE on 4 different systems and had the same problem even though everything worked fine. After keeping EOS up to date the problem is gone, don’t know what fixed it.

One of the higher ups will come by and give comfort and reason for this, relax nothing will crash & burn. :innocent:

I don’t know, the reason for this message… nonetheless did you check what journalctl -b prints out? Maybe you’ll find some errors+context that could explain what you see.
I can only guess that one needed unit does not load and related ones are waiting for it to start up (just a guess)

Cheers

1 Like

I think I remember how mine got fixed. I had a start job is running (don’t remember which one, sorry) that slowed up my boot. I installed haveged 1.9.8-1 and everything was fine after.

Hope heniekhardkor is still with us. :thinking:

Strange enough I get the same message…

$ systemd-analyze
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
$ systemctl list-jobs
JOB UNIT                           TYPE  STATE  
 65 fstrim.timer                   start waiting
 64 shadow.timer                   start waiting
 84 man-db.timer                   start waiting
  2 multi-user.target              start waiting
 68 pamac-cleancache.timer         start waiting
 85 tlp.service                    start waiting
  1 graphical.target               start waiting
 63 timers.target                  start waiting
 43 systemd-time-wait-sync.service start running
 24 time-sync.target               start waiting
 66 logrotate.timer                start waiting
 76 updatedb.timer                 start waiting

:thinking:

ye i’m here, i will check this package when i get home tomorrow;) thx

if you would click on “Resolve system issues” from the welcome app you would get systemd-time-wait-sync disabled

or do it by hand:

sudo systemctl stop systemd-time-wait-sync
sudo systemctl disable systemd-time-wait-sync

When I’m checking it now again it works without any error…


$ systemd-analyze blame
40min 28.822s systemd-time-wait-sync.service                                   >
      29.962s man-db.service                                                   >
       5.801s updatedb.service                                                 >
       5.159s systemd-random-seed.service                                      >
       4.629s lightdm.service                                                  >
       4.186s systemd-logind.service                                           >
       3.925s systemd-rfkill.service                                           >
       2.329s upower.service                                                   >
       2.105s lvm2-monitor.service                                             >
       2.078s systemd-backlight@backlight:intel_backlight.service              >
       1.951s dev-sda1.device                                                  >
       1.534s tlp.service                                                      >
       1.143s systemd-timesyncd.service                                        >
        838ms systemd-journald.service                                         >
        830ms systemd-udevd.service                                            >
        387ms logrotate.service                                                >
        351ms ldconfig.service                                                 >
        329ms systemd-udev-trigger.service                                     >
        282ms udisks2.service                                                  >
        218ms accounts-daemon.service                                          >
        204ms user@1000.service                                                >
        184ms NetworkManager.service                                           >
        164ms polkit.service

Removing this service worked for me.

systemd−time−wait−sync is a system service that delays the start of units that depend on time−sync.target until the system time has been synchronized with an accurate time source by systemd−timesyncd.service.

systemd−timesyncd.service notifies on successful synchronization. systemd−time−wait−sync also tries to detect when the kernel marks the time as synchronized, but this detection is not reliable and is intended only as a fallback for other services that can be used to synchronize time (e.g., ntpd, chronyd).

I wonder why it takes ages to synchronize with an accurate time source…

https://www.freedesktop.org/software/systemd/man/systemd-time-wait-sync.service.html

It is not needed to wait for this, may on some very time sensible systems :wink:
It is not syncing the time itself this be done by systemd-timesyncd.service

And it was working before (when i add this to default settings) but seems to not work anymore on some systems.

ye that worked, thanks

we do include this fixes also inside welcome app:
detect-system-issues

1 Like