[Solved] ldconfig.service causes slow startup

OrigBitmancer · 2019-08-22 08:09:54

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.

graphical.target @1min 31.622s
└─lxdm.service @1min 31.620s
  └─systemd-user-sessions.service @1min 31.199s +415ms
    └─network.target @1min 31.193s
      └─dhcpcd.service @1min 22.333s +8.856s
        └─basic.target @1min 21.698s
          └─sockets.target @1min 21.698s
            └─org.cups.cupsd.socket @1min 21.697s
              └─sysinit.target @1min 20.829s
                └─systemd-update-done.service @1min 20.786s +42ms
                  └─ldconfig.service @47.657s +33.127s     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ouch!
                    └─local-fs.target @47.654s
                      └─media-old_other.mount @47.199s +454ms
                        └─systemd-fsck@dev-disk-by\x2dlabel-old_other.service @43.446s +3.750s
                          └─local-fs-pre.target @43.402s
                            └─systemd-tmpfiles-setup-dev.service @23.438s +5.217s
                              └─systemd-sysusers.service @17.334s +6.100s
                                └─systemd-remount-fs.service @16.933s +212ms
                                  └─systemd-fsck-root.service @12.973s +3.958s

How can I make the ldconfig.service run faster or go to the background? (nearly 6000 real load modules to process)

App startup in general is slow. How do I instrument this for debugging? (No apparent dmesg output)

Last edited by OrigBitmancer (2019-08-22 21:28:25)

Allan · 2019-08-22 11:18:07

My guess is that you can completely disable it. pacman runs ldconfig after updating anyway, so there should be no need for that service as long as you install software using pacman.

OrigBitmancer · 2019-08-22 14:10:51

I would never have checked that. Thanks!

Now, what debug info would help me speed up the delay in process startup?

Last edited by OrigBitmancer (2019-08-22 14:13:17)

V1del · 2019-08-22 14:21:35

strace an affected program and check where it hangs should be a good first step, post the output if you need help interpreting it.

OrigBitmancer · 2019-08-22 21:15:41

strace! D’oh! Thanks! It has been too long since I used it. I *think* I can still read the output. Very grateful, V1del!

OrigBitmancer · 2019-08-22 21:21:53

OrigBitmancer wrote:

How can I make the ldconfig.service run faster or go to the background? (nearly 6000 real load modules to process)
App startup in general is slow. How do I instrument this for debugging? (No apparent dmesg output)

Answers:
1) Disable ldconfig.service.

2) use strace(1) on the affected program.

V1del · 2019-08-23 07:12:04

Did you figure the cause and a fix?

OrigBitmancer · 2019-08-27 01:25:35

I can verify that the following code deleted the ldconfig.service calls during startup:

systemctl disable ldconfig.service
systemctl stop ldconfig.service

And now I start with a lot less delay.

I fear I should have started another thread with the strace(1) stuff. The notably slower apps (increased 3 - 4 times slower than they were) I notice most are Thunderbird, Mozilla, and Chrome.
All apps seem affected. There might be some ld.so interaction here, since this is a dynamic loader environment.

If there is no masking (local before system, for example) of dynamic libraries, is it kosher to play with the contents (and division) of /etc/ld.so.conf.d/*.conf ?
For instance,

cat  /etc/ld.so.conf.d/*.conf

yields

/usr/lib/
/usr/lib/ffmpeg3.4/
/usr/lib/R/lib
/usr/lib/libfakeroot
/usr/lib/gigedit
/usr/lib32/libfakeroot
/usr/lib32
/usr/lib/libgig
/usr/lib/linuxsampler
/usr/lib/octave/5.1.0
/usr/lib/opencollada
/usr/lib/openmpi
/usr/lib/perf

There are several thousand results for

find /usr/lib -name \*.so -ls |grep -v lrwx|wc -l

(almost 12000)
so the cleanup (?) might take a while.

Last edited by OrigBitmancer (2019-08-27 03:23:40)

Allan · 2019-08-27 08:03:01

You have a choice here - either ldconfig looks at all your libraries on startup, or libraries are first read when a program needs them. You used to have ldconfig taking ages during startup but then all future access to system libraries was cached and fast. Not anymore, which is why you notice large programs taking a while to load.

Don't adjust things in /etc/ld.so.conf.d/. You will only end up with issues...

xerxes_ · 2019-08-27 09:31:33

I noticed that ldconfig.service is run on startup only if something was updated. Am I right?

loqs · 2019-08-27 10:22:17

xerxes_ from the unit file

ConditionNeedsUpdate=|/etc
ConditionFileNotEmpty=|!/etc/ld.so.cache

OrigBitmancer · 2019-08-29 19:19:23

Thanks to Allan, xerxes_, V1del, and loqs for wisdom imparted.
I will now just suck it up and go refresh my soda when booting.
I update every day, so it is no wonder that this changes every time I reboot.

Arch Linux

#1 2019-08-22 08:09:54

[Solved] ldconfig.service causes slow startup

#2 2019-08-22 11:18:07

Re: [Solved] ldconfig.service causes slow startup

#3 2019-08-22 14:10:51

Re: [Solved] ldconfig.service causes slow startup

#4 2019-08-22 14:21:35

Re: [Solved] ldconfig.service causes slow startup

#5 2019-08-22 21:15:41

Re: [Solved] ldconfig.service causes slow startup

#6 2019-08-22 21:21:53

Re: [Solved] ldconfig.service causes slow startup

#7 2019-08-23 07:12:04

Re: [Solved] ldconfig.service causes slow startup

#8 2019-08-27 01:25:35

Re: [Solved] ldconfig.service causes slow startup

#9 2019-08-27 08:03:01

Re: [Solved] ldconfig.service causes slow startup

#10 2019-08-27 09:31:33

Re: [Solved] ldconfig.service causes slow startup

#11 2019-08-27 10:22:17

Re: [Solved] ldconfig.service causes slow startup

#12 2019-08-29 19:19:23

Re: [Solved] ldconfig.service causes slow startup

Board footer