Description of problem: Booting my systems takes a long time, over 2 minutes with Mageia 2. It took less than 20sec with Mageia 1. Version-Release number of selected component (if applicable): Mageia 2 How reproducible: Always Steps to Reproduce: 1. Install and update Mageia 1 2. Upgrade to Mageia 2 3. I have attached the output of dmesg. Please tell me if there is anything else I can provide. The longest break is after 49sec. Thank you, Jeff
Created attachment 2374 [details] output of dmesg showing the long boot process Longest break is after 49 seconds
Created attachment 2375 [details] boot.log
As a root run this command: urpmi systemd-tools Then as a normal user run this command: systemd-analyze plot > ~/boot.svg And attach boot.svg from your home directory. Then we can see what is taking so much time.
CC: (none) => sander.lepik
Attachment 2375 mime type: text/x-log => text/plain
Also, based on the line Failed to start Initialize hardware monitoring sensors try running, as root, "sensors-detect".
CC: (none) => davidwhodgins
Created attachment 2378 [details] systemd-analyze plot output
Colin, any ideas? It seems to be mount point (On_Ourserver) that is taking this time and holding back prefdm.
CC: (none) => mageia
If it's just the mount point then it's not really a problem. I commented it out of fstab after looking at the graph. The server got a clean install of Mageia 2 Beta 3, upgraded to 2 release, and I never setup the shares. I'll restart now and report.
The system boots up much faster now. It seems like under 30 seconds again, which the new graph seems to say (I think). Although I couldn't run "systemd-analyze" for several minutes after login. Is this because of sendmail and if so, then how do I fix that? Is it safe to remove sendmail or at least stop the service from starting? I'm not sending any e-mails from my system vis SMTP. Thank you, Jeff
Created attachment 2379 [details] systemd-analyze plot ourput after removing broken nfs share
(In reply to comment #8) > Is it safe to remove sendmail or at least stop the service from starting? Well, if you don't use it then it should be safe to turn it off. You can first disable it and see if this will cause any problems. If not then you can probably remove it if anything doesn't depend on it. Or you could replace it by one of these: $ urpmq --whatprovides sendmail-command msmtp|sendmail|postfix|dma|ssmtp
I disabled the sendmail service and now the entire boot process, according to systemd-analyze taken only 42.2s versus 216s with sendmail enabled. Also, is there a way to leave the nfs share enabled in fstab, but not have it hold-up the boot process if it can't mount? One of my other computers is a laptop, which won't always be on the same network as the server, but I'd rater not have to mount it explicitly every time I have to use it. Mageia 1 didn't seem to have the problem and neither did Mandriva before it. Thank you, Jeff
Re the nfs share: We consider any NFS share in fstab not marked with "nofail" to be a required share for login. Simply edit your fstab and put "nofail" in the options and it should not hold up the login screen, but still be mounted on boot. As for sendmail, I'm not sure, but I'd guess that it's not writing the correct pid file as specified in the header and thus it systemd doesn't consider it "started". That said, I've installed sendmail in my test VM and it does write it's PID correctly so it appears to be working properly. Perhaps you can check to see if there was some problem during upgrade and you've somehow got an old sendmail install or something?
Hmm, actually rebooting with sendmail installed shows the issue for me too. What I seem to see there is that the initscript intentionally delays itself until the hostname is set to something other than localhost. As sendmail contributes to the network.target, the NFS mounts will not start until sendmail is complete, and as the NFS mounts are considered as "essential" (due to lack of nofail option) for logins, the login screen is delayed too. So, assuming you just put "nofail" in fstab, then hopefully everything will work fine and sendmail can take it's time starting up. It does however seem like sendmail is just a bit broken in this regard. I'd probably recommend postfix if you need a full MTA. That's the one I use.
Silly question, but is this where I should put "nofail"? 192.168.0.102:/backup/PITA_Linux /backup/On_Ourserver nfs defaults,nofail 0 0 I don't need any MTA. I think sendmail was installed a long time ago because an MTA was required by LSB, but I could be wrong. I do remember that something kept complaining about not having an MTA and urpmi kept suggesting it.
In this case you can just replace "defaults" with "nofail" as "defaults" is what you use when you have nothing else to put in there! See "man fstab" for more details. FWIW, it's also a good idea to put '_netdev' in there too to mark it clearly as a network mount. 192.168.0.102:/backup/PITA_Linux /backup/On_Ourserver nfs _netdev,nofail 0 0
Should I open another bug report for sendmail or should I just change the summary of this one? --Jeff
Well I think sendmail is working as it internally intends to be honest. It's startup doesn't seem to hold up the availability of a login prompt, so I'd be tempted to just leave it.
My machine boots quickly now and the sendmail issue would be a different bug report, so I'm closing this one.
Status: NEW => RESOLVEDResolution: (none) => FIXED