Yet Another Slow Booting Thread

English Applications
#1

Sorry for the new thread, but I thought it best not to interrupt other discussions.

I have two systems. Call them SystemK and SystemM. I compare booting on the two systems.

With SystemK, the hard disk spins for a while (I go by the light indicating disk activity). Then there is what seems to be a longish period with almost no disk activity. Finally, the login screen comes up.

With SystemM, the hard disk spins for a while. Almost as soon as the disk activity stops, the login screen comes up.

I tried: systemd-analyze blame | grep -i networkman

For SystemK, I get:


         25.232s NetworkManager.service
          7.574s NetworkManager-wait-online.service

while, for SystemM, I get:


           283ms NetworkManager.service

It seems a good guess that the NetworkManager startup time is a big part of the problem.

What’s similar about the two systems:

  • Both are on the same physical computer (a Dell laptop);
  • Both use an encrypted LVM. In fact, they use the same encrypted LVM, but different root volumes within that LVM. Both use the same swap volume and the same home volume in that LVM, except that SystemM mounts the home volume as “/xhome”.

What’s different about the two systems:

  • SystemK runs the KDE desktop and uses KDM as login manager;
  • SystemM runs the MATE desktop and uses lightdm as login manager.

It is hard to see how those differences could matter, since the delays are there before the desktops start.

Oh, yes. There is one additional difference. And maybe this is the cause.

On SystemK, I am running “autofs”. In SystemM, I have not yet gotten around to configuring “autofs” (and might not ever bother).

But if that is the difference, it makes no sense. The whole idea of using “autofs”, instead of configuring network shares in “/etc/fstab”, is supposed to be to allow lazy mounting and to avoid having system startup delayed by network issues.

#2

Well seems like a good time to test it. remove autofs and see what happens

#3

Another point again not sure who it would effect things but which controls the boot??

#4

I’m more inclined to setup autofs on SystemM, and see if that slows down its boot.

#5

Neither. They are both booted from entries in Windows Boot Manager.

Each has its own separate “/boot” partition.

#6

Try removing this line from /usr/lib/systemd/system/autofs.service and see if it “fixes” the problem:

Before=systemd-logind.service

See also: http://bugzilla.opensuse.org/show_bug.cgi?id=905639

#7

No, that did not help.

So I put that line back, and instead removed the “After=” line.

That did not help either.

So I disabled autofs. And that did not help either.

So it must be something else that is the difference between the KDE and MATE systems. Hmm, maybe I should also disable “rpcbind”, since the only reason that is running is to support “autofs”.

On the “autofs.service” definition: It seems to me that the “Before=” line should be there. By the time a user logs in, autofs should be running. But the “After=” line doesn’t seem appropriate. As far as I know, “autofs” does not depend on the network. Actually mounting a network file system when needed would depend on the network. But “autofs” is just there to make sure that someone is looking at access to those paths so that mounting can be initiated when needed.

If a user tries to access a network share when there is a network problem, he will get a network timeout. And that’s what is supposed to happen. If a user tries to access a network share before “autofs” is running, he would probably get a “Bad path” or similar message. And that’s would be a bogus message. That’s why I think the “Before=” is correct.

#8

I just remembered another difference.

SystemK is running “sendmail” while SystemM is running “postfix”.

I’m not sure why or whether those would have different network requirements.

#9

Hi,

I have exactly the same issue here not able to adress and looking for some solution around.
It occured after some updates maybe a week or four days ago.

Interesting is, when I installed openSUSE 13.2 and using wicked for the network it boots in about
32 seconds, then i replace it with the network manager service, then my boot suddenly went from
32 seconds to 8 seconds, a big difference.

After the said updates which I don’t know until now network manager service became so slow
from 25 seconds to more than 30 seconds and system seems to hang like the op described.
It is showing also a text login that I ignored and just wait and the graphical login will show-up.

With the slowness of the network manager service I reverted to wicked and I notice a significant
improvement of it and booting time improve to 15 seconds but I cann’t achieved the 8 seconds
booting time now. This machine also used to boot in 5-8 seconds depending on the apparmor service time spent
during boot and network manager service was quick and never probably spent a second to initialize.