Too long boot time

I have come back to OpenSuse after a long time. I had downloaded every release for few years, but had a problem of getting the live dvd to boot, but the latest 13.2 booted in quite well and I installed it. I have the Gnome version and it is very responsive. The only problem I found yet is the longer boot time than the Debian and Ubuntu distros I have. Yesterday, I upgraded/downgraded my 13.2 install to Tumbleweed as it is the rolling version. Everything works well, the responsiveness is very good, I might even say, much better than Ubuntu. That is, once it boots up. The boot time is too long. I have the reccomended btrfs system. I don’t mind the longer boot time, considering the high responsiveness.

Is there a way to make it boot faster?
Regards!

Well, the first thing is to undertake some auditing. Maybe there are some services that aren’t needed, or processes that slow the boot down for some reason

systemd-analyze blame
netstat -tap |grep LISTEN

How much memory do you have?

free

Starting with that information, it may be possible to advise further.

Thank you. Here is the data.

czanat@linux:~> systemd-analyze blame
55.564s NetworkManager.service
52.590s ModemManager.service
52.588s nscd.service
52.244s display-manager.service
8.598s systemd-udev-settle.service
1.559s \x2esnapshots.mount
1.543s var-tmp.mount
1.540s postfix.service
1.506s lvm2-activation-early.service
1.292s polkit.service
1.266s var-spool.mount
1.170s var-opt.mount
1.066s accounts-daemon.service
1.032s lvm2-activation.service
871ms systemd-tmpfiles-setup.service
772ms systemd-udev-root-symlink.service
768ms sys-kernel-debug.mount
766ms dev-mqueue.mount
765ms dev-hugepages.mount
762ms var-log.mount
744ms var-lib-pgsql.mount
698ms var-lib-named.mount
697ms var-lib-mailman.mount
682ms var-crash.mount
681ms usr-local.mount
570ms systemd-readahead-replay.service
557ms tmp.mount
548ms srv.mount
530ms apparmor.service
455ms systemd-udev-trigger.service
420ms colord.service
396ms systemd-tmpfiles-setup-dev.service
358ms alsa-restore.service
356ms vboxadd.service
355ms bluetooth.service
354ms systemd-user-sessions.service
353ms avahi-daemon.service
351ms wpa_supplicant.service
350ms rc-local.service
323ms dev-disk-by\x2duuid-703fb593\x2d1b8a\x2d4bed\x2d9a40\x2d4ab8d8a
319ms opt.mount
251ms systemd-remount-fs.service
236ms systemd-readahead-collect.service
223ms rtkit-daemon.service
173ms systemd-backlight@backlight:acpi_video0.service
150ms systemd-random-seed.service
146ms systemd-modules-load.service
126ms home.mount
124ms systemd-sysctl.service
118ms boot-grub2-x86_64\x2defi.mount
114ms udisks2.service
92ms plymouth-read-write.service
75ms lvm2-lvmetad.service
71ms auditd.service
70ms user@1000.service
65ms dm-event.service
44ms cycle.service
44ms systemd-update-utmp.service
36ms plymouth-start.service
32ms sshd.service
32ms boot-grub2-i386\x2dpc.mount
23ms systemd-rfkill@rfkill0.service
22ms systemd-rfkill@rfkill1.service
19ms systemd-update-utmp-runlevel.service
12ms systemd-vconsole-setup.service
12ms systemd-logind.service
10ms upower.service
9ms kmod-static-nodes.service
6ms systemd-journal-flush.service
5ms sys-fs-fuse-connections.mount
5ms iscsi.service
4ms systemd-udevd.service
3ms systemd-readahead-done.service
1ms systemd-rfkill@rfkill2.service
1ms systemd-rfkill@rfkill3.service

czanat@linux:~> netstat -tap |grep LISTEN
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 *:ssh : LISTEN -
tcp 0 0 localhost:ipp : LISTEN -
tcp 0 0 localhost:smtp : LISTEN -
tcp 0 0 *:ssh : LISTEN -
tcp 0 0 localhost:ipp : LISTEN -
tcp 0 0 localhost:smtp : LISTEN

czanat@linux:~> free
total used free shared buffers cached
Mem: 2879696 1234148 1645548 87868 912 646808
-/+ buffers/cache: 586428 2293268
Swap: 2654204 0 2654204

linux:/home/czanat # netstat -tap |grep LISTEN
tcp 0 0 *:ssh : LISTEN 886/sshd
tcp 0 0 localhost:ipp : LISTEN 869/cupsd
tcp 0 0 localhost:smtp : LISTEN 1151/master
tcp 0 0 *:ssh : LISTEN 886/sshd
tcp 0 0 localhost:ipp : LISTEN 869/cupsd
tcp 0 0 localhost:smtp : LISTEN

data as root

On 2014-11-09 10:56, deano ferrari wrote:

> Code:
> --------------------
> systemd-analyze blame
> --------------------

I prefer “systemd-analyze critical-chain”. It highlights in red the
items causing more delay.

On 2014-11-09 11:26, Chdslv wrote:

> Thank you. Here are the data.
>
>> czanat@linux:~> systemd-analyze blame
>> 55.564s NetworkManager.service
>> 52.590s ModemManager.service
>> 52.588s nscd.service
>> 52.244s display-manager.service
>> 8.598s systemd-udev-settle.service
>> 1.559s \x2esnapshots.mount
>> 1.543s var-tmp.mount

A comment: When pasting here computer commands and such, please use a
CODE BLOCK, so that the forum software doesn’t do silly things like
converting URLS to tiny urls, wrap lines, or otherwise hide or alter the
commands you entered. You get them by clicking on the ‘#’ button in the
forum editor. http://susepaste.org/images/15093674.jpg


czanat@linux:~> systemd-analyze blame
55.564s NetworkManager.service
52.590s ModemManager.service
52.588s nscd.service
52.244s display-manager.service
8.598s systemd-udev-settle.service
1.559s \x2esnapshots.mount
1.543s var-tmp.mount

display-manager.service is taking a lot. Perhaps you have automatic
login enabled, so you are counting as boot time what is in fact “login
to the desktop” time. That is, gnome or kde starting.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Carlos, I never use automatic login in any distros I use.
It takes quite a long time to come to the login window, and from login to desktop to appear is shorter.

Here is what you asked for

czanat@linux:~> 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 @1min 15.816s
└─multi-user.target @1min 15.816s
  └─cron.service @1min 15.816s
    └─postfix.service @1min 14.262s +1.552s
      └─network.target @1min 14.261s
        └─NetworkManager.service @21.180s +53.080s
          └─basic.target @21.062s
            └─timers.target @21.061s
              └─systemd-tmpfiles-clean.timer @21.061s
                └─sysinit.target @21.061s
                  └─sys-fs-fuse-connections.mount @1min 15.165s +4ms
                    └─systemd-modules-load.service @3.492s +3ms
                      └─systemd-readahead-replay.service @2.393s +833ms
                        └─system.slice
                          └─-.slice

The NetworkManager service takes a long time to start

NetworkManager.service @21.180s +53.080

I’ll leave others to comment further.

On 2014-11-09 20:06, Chdslv wrote:
>
> Carlos, I never use automatic login in any distros I use.
> It takes quite a long time to come to the login window, and from login
> to desktop to appear is shorter.
>
> Here is what you asked for
>
>
> Code:
> --------------------

> └─postfix.service @1min 14.262s +1.552s
> └─NetworkManager.service @21.180s +53.080s
> └─systemd-readahead-replay.service @2.393s +833ms
> --------------------

53 seconds for the network manager. Why, no idea, but that’s what need’s
analyzing. Are you using dhcp? Sometimes it is slow. Try using a fixed
IP instead. There are two different dhcp daemons: some times one of them
doesn’t work right on a particular network and you have to switch to the
other.

If you don’t find a solution for that, you can ask in the network
subforum here (post the critical-chain output showing that you have a
problem with network manager being too slow).


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Thanks, Carlos, I’ll move my question there. Regards!

I read through the whole post again, and I think I must ask this question again here. I am copying syetemd-analyze blame top part to show what I see.

czanat@linux:~> systemd-analyze blame
         55.564s NetworkManager.service
         52.590s ModemManager.service
         52.588s nscd.service
         52.244s display-manager.service
          8.598s systemd-udev-settle.service
          1.559s \x2esnapshots.mount
          1.543s var-tmp.mount
          1.540s postfix.service
          1.506s lvm2-activation-early.service
          1.292s polkit.service
          1.266s var-spool.mount

It appears the time between systemd-udev-settle.service to display-manager.service takes the most time lag, nearly 44 seconds.
I checked the same with my Debian Testing install. Both have Gnome 3.14.1 and systemd. The same systemd-analyze blame gives this result below. I am pasting the whole output here. As you see it is 21 seconds, while my Opensuse takes 55 seconds.

czanat@czanat:~$ systemd-analyze blame
         21.238s nmbd.service
         20.883s samba-ad-dc.service
         11.119s systemd-udev-settle.service
          9.210s libvirtd.service
          7.957s ModemManager.service
          7.529s binfmt-support.service
          7.031s NetworkManager.service
          6.665s accounts-daemon.service
          4.894s bluetooth.service
          4.884s lm-sensors.service
          4.882s systemd-logind.service
          4.799s pppd-dns.service
          4.790s minissdpd.service
          4.788s rc-local.service
          4.788s vboxadd.service
          4.786s virtualbox-guest-utils.service
          4.785s virtualbox.service
          4.482s avahi-daemon.service
          3.862s wicd.service
          3.328s systemd-fsck-root.service
          2.636s dev-mqueue.mount
          2.525s dev-hugepages.mount
          2.524s sys-kernel-debug.mount
          2.089s rsyslog.service
          2.068s keyboard-setup.service
          2.031s exim4.service
          1.526s systemd-modules-load.service
          1.386s polkitd.service
          1.273s systemd-tmpfiles-setup-dev.service
          1.264s udisks2.service
          1.264s systemd-rfkill@rfkill0.service
           995ms sys-fs-fuse-connections.mount
           740ms packagekit.service
           653ms lvm2-activation-early.service
           608ms systemd-sysctl.service
           574ms nfs-common.service
           545ms ntp.service
           455ms wpa_supplicant.service
           453ms systemd-rfkill@rfkill1.service
           438ms systemd-user-sessions.service
           389ms smbd.service
           360ms networking.service
           356ms colord.service
           333ms proc-sys-fs-binfmt_misc.mount
           316ms rpcbind.service
           303ms kmod-static-nodes.service
           233ms systemd-random-seed.service
           226ms ebtables.service
           222ms systemd-tmpfiles-setup.service
           207ms user@114.service
           206ms gdm.service
           194ms systemd-udevd.service
           182ms systemd-backlight@backlight:acpi_video0.service
           178ms systemd-udev-trigger.service
           170ms systemd-rfkill@rfkill3.service
           170ms systemd-rfkill@rfkill2.service
           167ms kbd.service
           155ms console-setup.service
           148ms systemd-remount-fs.service
           140ms hdparm.service
           128ms dev-disk-by\x2duuid-703fb593\x2d1b8a\x2d4bed\x2d9a40\x2d4ab8d8a
           122ms udev-finish.service
           112ms virtualbox-guest-x11.service
           103ms lightdm.service
            92ms user@1000.service
            75ms speech-dispatcher.service
            69ms gdomap.service
            63ms upower.service
            61ms systemd-update-utmp.service
            49ms rtkit-daemon.service
            46ms libvirt-guests.service
            38ms hddtemp.service
            25ms lvm2-activation.service
            24ms lvm2-monitor.service
             8ms systemd-journal-flush.service
             7ms vboxadd-service.service
             3ms qemu-system-x86.service
             3ms systemd-update-utmp-runlevel.service
             1ms mdm.service

My Debian install responds quite well after booting, just like my Opensuse, but this long booting time is really troublesome, and I don’t know how to get out of this problem. Hope you guys could find a way. Thanks.

You are using networkmanager Have you tried wicked? How is connected.

You re-posted this same thread to the Networking Forum.
Unless there is a very good reason, the general rule is to not cross-post.

I provided your probable solution there.
https://forums.opensuse.org/showthread.php/502389-Too-long-boot-time-a-network-problem

TSU

I was adviced to go there, but they didn’t find a reply there, and once I read through the whole post here again, I came back here. I think it is a boot problem, so this is the correct place. I’ll go there to check you reply, but still I think it is a boot problem, taking too much time to start the display manager service.

On 2014-11-10 19:26, Chdslv wrote:
>
> I read through the whole post again, and I think I must ask this
> question again here. I am copying syetemd-analyze blame top part to show
> what I see.

No, “blame” is not that simple to analyze as “critical-chain”.
Somethings appear to take long, but it is because they are waiting for
something else. It is that something else which is important.

I would ignore the “blame” output.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-11-10 19:46, tsu2 wrote:
>
> You re-posted this same thread to the Networking Forum.
> Unless there is a very good reason, the general rule is to not
> cross-post.

I suggested him to ask on the networking forum why
“NetworkManager.service” takes almost a minute to start, which is a
network related question, once that the boot problem delay studied here
has pointed at that culprit. Not to post there the same exact same
question as here. I have not seen yet his other post, but that should
not be a double post, rather a division and specialization of labor. :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Well, I am not getting any answer to my problem here or in the other post. It is still booting too long, whereas the Debian install in the same laptop using the same Wifi boots much faster.

I am happy to announce that my too long boot problem had corrected itself automatically, which is a + to OpenSuse.
Here is some data:

czanat@linux:~> systemd-analyze blame
          9.109s systemd-udev-settle.service
          8.331s display-manager.service
          7.847s ModemManager.service
          7.763s NetworkManager.service
          7.713s nscd.service
          1.602s \x2esnapshots.mount
          1.544s var-tmp.mount
          1.494s postfix.service
          1.483s var-spool.mount
          1.430s var-opt.mount
          1.321s lvm2-activation.service
          1.260s dev-disk-by\x2duuid-703fb593\x2d1b8a\x2d4bed\x2d9a40\x2d4ab8d8a
          1.119s lvm2-activation-early.service
          1.017s var-log.mount
          1.000s var-lib-pgsql.mount
           979ms var-lib-named.mount
           825ms var-lib-mailman.mount
           814ms colord.service
           805ms var-crash.mount
           803ms usr-local.mount
           705ms systemd-tmpfiles-setup-dev.service
           630ms tmp.mount
           623ms systemd-readahead-replay.service
           609ms srv.mount
           583ms systemd-udev-root-symlink.service
           576ms sys-kernel-debug.mount
           575ms dev-mqueue.mount
           575ms dev-hugepages.mount
           515ms opt.mount
           463ms systemd-udev-trigger.service
           434ms apparmor.service
           428ms home.mount
           395ms boot-grub2-x86_64\x2defi.mount
           380ms systemd-tmpfiles-setup.service
           340ms plymouth-read-write.service
           289ms alsa-restore.service
           287ms bluetooth.service
           287ms vboxadd.service
           285ms systemd-user-sessions.service
           283ms avahi-daemon.service
           281ms wpa_supplicant.service
           278ms systemd-remount-fs.service
           273ms systemd-update-utmp.service
           268ms rtkit-daemon.service
           251ms systemd-backlight@backlight:acpi_video0.service
           183ms systemd-modules-load.service
           174ms systemd-random-seed.service
           173ms systemd-rfkill@rfkill1.service
           173ms udisks2.service
           173ms systemd-rfkill@rfkill0.service
           166ms user@1000.service
           159ms rc-local.service
           146ms systemd-sysctl.service
           120ms polkit.service
           115ms lvm2-lvmetad.service
           106ms dm-event.service
            83ms auditd.service
            50ms systemd-readahead-done.service
            47ms systemd-readahead-collect.service
            40ms cycle.service
            38ms boot-grub2-i386\x2dpc.mount
            28ms systemd-update-utmp-runlevel.service
            23ms sshd.service
            20ms systemd-udevd.service
            16ms plymouth-start.service
            12ms accounts-daemon.service
            11ms systemd-vconsole-setup.service
             9ms systemd-logind.service
             9ms upower.service
             7ms systemd-journal-flush.service
             7ms iscsi.service
             4ms kmod-static-nodes.service
             4ms sys-fs-fuse-connections.mount
             1ms systemd-rfkill@rfkill3.service
             1ms systemd-rfkill@rfkill2.service

and,

czanat@linux:~> 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 @24.985s
└─multi-user.target @24.985s
  └─cron.service @24.985s
    └─postfix.service @23.490s +1.494s
      └─network.target @23.488s
        └─NetworkManager.service @15.724s +7.763s
          └─basic.target @15.435s
            └─timers.target @15.434s
              └─systemd-tmpfiles-clean.timer @15.434s
                └─sysinit.target @15.434s
                  └─apparmor.service @14.999s +434ms
                    └─systemd-tmpfiles-setup.service @14.617s +380ms
                      └─local-fs.target @14.612s
                        └─local-fs-pre.target @3.565s
                          └─systemd-remount-fs.service @3.282s +278ms
                            └─systemd-readahead-replay.service @2.589s +623ms
                              └─system.slice
                                └─-.slice

Thanks to all, who replied.