systemd-analyze critical-chain: Improvements possible?

Hello

My oS TW Lappy is continuing to delight me, but i wondered if i might be able to get its boot time sharpened up a bit? I do not know if this is sufficient initial info, but so far i have this:

linux-763v:~> **systemd-analyze**Startup finished in 2.969s (kernel) + 14.143s (initrd) + 17.205s (userspace) = **34.317s**

linux-763v:~> **systemd-analyze critical-chain**
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @17.196s
└─multi-user.target @17.196s
  └─teamviewerd.service @17.035s +160ms
    └─network-online.target @17.032s
      └─NetworkManager-wait-online.service @3.695s +**13.336s**
        └─NetworkManager.service @3.623s +69ms
          └─SuSEfirewall2_init.service @3.279s +342ms
            └─sysinit.target @3.278s
              └─cryptsetup.target @3.278s
                └─systemd-cryptsetup@cr_ata\x2dSAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960\x2dpart5.service @811ms +2.467s
                  └─dev-disk-by\x2did-ata\x2dSAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960\x2dpart5.device @720ms
linux-763v:~> 

Thanks.

Hi
Have a look at the file /etc/sysconfig/network/config file and adjust the WAIT_FOR_INTERFACES and NM_ONLINE_TIMEOUT options if using NetworkManager.

This parameter can never be sensibly lowered - only increased. If it is set larger than actual time NM needs, lowering it does not buy you anything. If it is already set smaller than time NM needs, startup continues before network is up, probably causing problems to some followup service. And if no service needs network to be up on startup, simply disabling NetworkManager-wait-online.service is far more simple and better.

The actual question is why NM needs so long to be up.

Try disabling ipv6 from yast> network settings

Additional Info:

linux-763v:~> **systemd-analyze blame**
         16.688s dracut-initqueue.service
         16.218s systemd-cryptsetup@cr_ata\x2dSAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960\x2dpart4.service
         11.939s NetworkManager-wait-online.service
          2.434s systemd-cryptsetup@cr_ata\x2dSAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960\x2dpart5.service
          2.297s postfix.service
          1.411s SuSEfirewall2.service
           847ms apparmor.service
           829ms display-manager.service
           531ms SuSEfirewall2_init.service
           517ms var-opt.mount
           511ms var-lib-mariadb.mount
           508ms srv.mount
           505ms var-log.mount
           499ms var-lib-pgsql.mount
           498ms usr-local.mount
           497ms var-cache.mount
           492ms var-tmp.mount
           490ms var-lib-named.mount
           487ms var-lib-machines.mount
           475ms var-lib-libvirt-images.mount
           468ms var-lib-mailman.mount
           463ms var-lib-mysql.mount
           462ms ModemManager.service
           462ms \x2esnapshots.mount
           458ms dev-sda3.device
           455ms boot-grub2-i386\x2dpc.mount
           448ms upower.service
           384ms vboxdrv.service
           354ms initrd-switch-root.service
           349ms lm_sensors.service
           250ms systemd-fsck@dev-mapper-cr_ata\x2dSAMSUNG_SSD_PM810_2.5__256GB_S0N4NEAZB01960\x2dpart5.service
           241ms var-crash.mount
           215ms btrfsmaintenance-refresh.service
           194ms mcelog.service
           161ms dracut-cmdline.service
           161ms boot-grub2-x86_64\x2defi.mount
           156ms nscd.service
lines 1-37

Thanks. I went to YaST - System - Network Settings, but it reminded me that

Network is currently handled by NetworkManager or completely disabled. YaST is unable to configure some options.
The former is true, i deliberately use NM as i use a VPN & frequently change my IP. FWIW, after acknowledging that warning i saw in YaST that its “Enable iPv6” box is unticked.

I went into NM & found i could not disable the Wired Connection IPv6 setting [each time i did, accepted & closed, then reopened, it was back to “[i]Automatic”]. As i mainly use WiFi not Ethernet on this Lappy & currently have no Ethernet cable connected], i’m not too worried about this. On the other hand & happily, the equivalent setting in WiFi did “stick”.

After rebooting, i was pleased to find that from the Login screen to having my desktop up was now only 14 seconds, with which i’m most happy compared to when i created this thread.

Oddly though, when i re-ran each of those earlier commands, there’s only a few seconds [max] shaved off here & there, but nothing “big” to explain the dramatic actual improvement.

Thanks all for your help here. I regard this matter as solved now.

When finding some unused btrfs timers enabled with TW 20171222 I revisited the boot process and ended up with:

erlangen:~ # systemd-analyze
Startup finished in 1.740s (kernel) + 757ms (initrd) + **1.835s** (userspace) = 4.333s
erlangen:~ # systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @**1.831s**
└─display-manager.service @1.266s +564ms
  └─apache2.service @1.006s +258ms
    └─time-sync.target @1.002s
      └─ntpd.service @947ms +55ms
        └─network.target @943ms
          └─NetworkManager.service @858ms +85ms
            └─dbus.service @798ms
              └─basic.target @789ms
                └─sockets.target @789ms
                  └─cups.socket @789ms
                    └─sysinit.target @787ms
                      └─systemd-update-utmp.service @783ms +3ms
                        └─auditd.service @766ms +16ms
                          └─systemd-tmpfiles-setup.service @746ms +19ms
                            └─local-fs.target @746ms
                              └─home\x2dHDD.mount @657ms +88ms
                                └─systemd-fsck@dev-disk-by\x2did-ata\x2dST2000DM001\x2d1CH164_W3408N5F\x2dpart6.service @475ms +180ms
                                  └─local-fs-pre.target @475ms
                                    └─lvm2-monitor.service @127ms +347ms
                                      └─lvm2-lvmetad.service @142ms
                                        └─lvm2-lvmetad.socket @120ms
                                          └─-.slice
erlangen:~ #