updatedb and man-db delay bootup - any workaround?

mcloaked · 2019-08-29 17:46:35

Does anyone know a workaround to stop the updatedb and man-db services from delaying bootup as illustrated by:

[mike@lenovo2 ~]$ sudo systemd-analyze blame
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
[mike@lenovo2 ~]$ sudo systemctl list-jobs  
JOB UNIT             TYPE  STATE  
474 updatedb.service start running

1 jobs listed.
[mike@lenovo2 ~]$ sudo systemd-analyze blame
    7min 36.658s updatedb.service
     2min 2.518s man-db.service
         14.410s lvm2-monitor.service
         11.863s iwd.service
         11.861s lm_sensors.service
         11.852s chronyd.service
         11.845s iptables.service
         11.840s systemd-logind.service
         11.818s logrotate.service
         10.989s udisks2.service
         10.668s ldconfig.service
         10.290s initrd-switch-root.service
          5.797s polkit.service
          4.239s systemd-hwdb-update.service
          4.120s systemd-journal-flush.service
          3.661s systemd-udevd.service
          3.202s systemd-sysusers.service
          2.454s systemd-modules-load.service
          2.131s upower.service

Trilby · 2019-08-29 17:48:08

Are they actually delaying anything? They should run in the background while you are already working in your desktop or whatever session you boot into.

mcloaked · 2019-08-29 17:56:54

Trilby wrote:

Are they actually delaying anything? They should run in the background while you are already working in your desktop or whatever session you boot into.

They should run in background but once the boot process reaches just before the graphical target the boot process list shows " a start job is running for locate database..." with a time like 21s and unlimited and it takes a minute or so before it reaches the graphical target, and then once the processing of the greeter screen begins it takes much longer than usual to get to the login prompt. It seems only to do this if I haven't booted the laptop for a few days though. Once I have logged in to the plasma desktop then I can start konsole and issue the commands I quoted in the previous post.

loqs · 2019-08-29 18:03:34

man systemd.timer wrote:

Persistent=
Takes a boolean argument. If true, the time when the service unit
was last triggered is stored on disk. When the timer is activated,
the service unit is triggered immediately if it would have been
triggered at least once during the time when the timer was
inactive. This is useful to catch up on missed runs of the service
when the machine was off. Note that this setting only has an effect
on timers configured with OnCalendar=. Defaults to false.

Edit:
Did timers.target wait for those expired timer units to complete?

Last edited by loqs (2019-08-29 18:06:29)

mcloaked · 2019-08-29 18:24:56

loqs wrote:

man systemd.timer wrote:
Persistent=
Takes a boolean argument. If true, the time when the service unit
was last triggered is stored on disk. When the timer is activated,
the service unit is triggered immediately if it would have been
triggered at least once during the time when the timer was
inactive. This is useful to catch up on missed runs of the service
when the machine was off. Note that this setting only has an effect
on timers configured with OnCalendar=. Defaults to false.
Edit:
Did timers.target wait for those expired timer units to complete?

Having never altered the 'persistent=' setting on any system timer I looked at four timer files:

[mike@lenovo2 ~]$ cat /usr/lib/systemd/system/man-db.timer 
[Unit]
Description=Daily man-db regeneration
Documentation=man:mandb(8)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

[mike@lenovo2 ~]$ cat /usr/lib/systemd/system/updatedb.timer 
[Unit]
Description=Daily locate database update

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[mike@lenovo2 ~]$ cat /usr/lib/systemd/system/multi-user.target.wants/man-db.timer
[Unit]
Description=Daily man-db regeneration
Documentation=man:mandb(8)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

[mike@lenovo2 ~]$ cat /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer 
[Unit]
Description=Daily locate database update

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

All these have Persistent=true which means it will start the associated timer instantly if it was running presumably at the time of last shutdown? Should some or all these be set to false?

Interestingly another machine which does not exhibit these problems does not have the files:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
or
/usr/lib/systemd/system/updatedb.timer

at all - I wonder if this laptop should have those files at all?

Edit: These two files are installed if the mlocate package is installed - on the machine where it isn't a problem the mlocate package is not installed!

Last edited by mcloaked (2019-08-29 18:35:33)

judd1 · 2019-08-29 18:39:18

https://bbs.archlinux.org/viewtopic.php?id=242344

loqs · 2019-08-29 18:41:27

/usr/lib/systemd/system/multi-user.target.wants/man-db.timer is supplied by man-db.
Do you use man or locate on that system?

mcloaked · 2019-08-29 18:50:50

loqs wrote:

/usr/lib/systemd/system/multi-user.target.wants/man-db.timer is supplied by man-db.
Do you use man or locate on that system?

On the laptop I have both man and mlocate and it seems that the two associated databases are updated at boot:

[mike@lenovo2 ~]$ systemctl status man-db.timer
● man-db.timer - Daily man-db regeneration
   Loaded: loaded (/usr/lib/systemd/system/man-db.timer; disabled; vendor preset: disabled)
   Active: active (waiting) since Thu 2019-08-29 18:33:18 BST; 1h 9min ago
  Trigger: Fri 2019-08-30 00:00:00 BST; 4h 17min left
     Docs: man:mandb(8)

Aug 29 18:33:18 lenovo2 systemd[1]: Started Daily man-db regeneration.
[mike@lenovo2 ~]$ systemctl status updatedb.timer
● updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static; vendor preset: disabled)
   Active: active (waiting) since Thu 2019-08-29 18:33:18 BST; 1h 9min ago
  Trigger: Fri 2019-08-30 00:00:00 BST; 4h 16min left

Aug 29 18:33:18 lenovo2 systemd[1]: Started Daily locate database update.

More often than not I find files with the find command, which although it's much slower than the locate command, does work. So if I uninstall the mlocate package presumably the database update won't then be running at boot (that is what took about 7 minutes, whereas the man-db update took two seconds during the same boot).

Edit: After rebooting the machine the boot was very quick with the timers above not running the database updates -

[mike@lenovo2 aur]$ sudo systemd-analyze
Startup finished in 1.132s (kernel) + 1.714s (initrd) + 6.939s (userspace) = 9.786s 
graphical.target reached after 6.939s in userspace

So in the absence of a real need for the locate command uninstalling the mlocate package looks like the easy way to work around the problem on my machine. I also looked at the status of the two timers above after the reboot, and the remaining time to the next trigger was the same as just before shutdown, and still counting down - so another way would I guess be to check if the database updates were running before shutting down - and if not wait till they complete and then presumably they won't be triggered during the next boot!

Last edited by mcloaked (2019-08-29 19:30:48)

Arch Linux

#1 2019-08-29 17:46:35

updatedb and man-db delay bootup - any workaround?

#2 2019-08-29 17:48:08

Re: updatedb and man-db delay bootup - any workaround?

#3 2019-08-29 17:56:54

Re: updatedb and man-db delay bootup - any workaround?

#4 2019-08-29 18:03:34

Re: updatedb and man-db delay bootup - any workaround?

#5 2019-08-29 18:24:56

Re: updatedb and man-db delay bootup - any workaround?

#6 2019-08-29 18:39:18

Re: updatedb and man-db delay bootup - any workaround?

#7 2019-08-29 18:41:27

Re: updatedb and man-db delay bootup - any workaround?

#8 2019-08-29 18:50:50

Re: updatedb and man-db delay bootup - any workaround?

Board footer