long bootup time?

[chrismurphy]

Is it reasonable for sendmail and client to take 2 minutes?

[root@f18v ~]# systemd-analyze
Startup finished in 2977ms (kernel) + 1102ms (initramfs) + 125597ms (userspace) = 129678ms
[root@f18v ~]# systemd-analyze blame
 60277ms sm-client.service
 60215ms sendmail.service
  1591ms systemd-udev-settle.service
  1200ms plymouth-start.service
   581ms firewalld.service
{snip}

[DBelton]

I had the same issue when I first installed F18 here.

But, I did what I usually do.. flush sendmail down the toilet

Since I really don't use sendmail, I just removed it with yum. Wish there was the custom package selection during the install so that I could have just not installed it at all, though.

[chepioq]

I don't use sendmail, but when I want remove it with yum, yum also remove redhat-lsb, and I need this package for my conky...

Take care dependencies when you remove sendmail...

[marko]

Originally Posted by DBelton

Wish there was the custom package selection during the install so that I could have just not installed it at all, though.

What? They got rid of custom package installation in anaconda for Fedora 18?

[DBelton]

yep. No custom package installation in the F18 anaconda. So now it takes me a few hours to go in and remove packages after the install, and add others in.

I believe they have changed the dependencies for redhat-lsb now as well. Sendmail isn't a dependency any more. You can safely can sendmail without it removing redhat-lsb.

But even if you can't completely remove it, you can mask the service to prevent it from starting.

[Dr.Diesel]

You can also mask both of these, leaving them installed buy disabled.

As root:

systemctl mask sm-client.service sendmail.service

Reboot twice to give prefetch a chance to adjust.

Lots more good stuff here:

http://www.harald-hoyer.de/personal/...5-to-3-seconds

[chrismurphy]

systemctl mask is brute force, it prevents even manual startup of the service, in which case you're better off just removing the package. Instead, systemctl disable will at least allow one time (until next reboot) use of 'systemctl start'.

[DBelton]

For some reason, systemctl disable wouldn't keep sendmail from starting here. I believe there is something (possibly NetworkManager?) that starts it up, and disabling it with systemctl wouldn't prevent it from starting.

Now, I didn't really try disabling it after installing F18, but it was that way on F17. I just removed it on F18.

[chrismurphy]

Ha ok, well in that case either mask or uninstalling it was the brute force action required to get the desired result.

[lsatenstein]

I went with KDE. KDE gives you the gui interface to services, including bluetooth and smart card. I disable their startup, and from the same interface you should be able to disable sendmail.

As well, when booting up after some upgrades, Gnome, KDE, etc. they run through all the bin files collecting locations for icons, programs etc. This cached information speeds up gui program startups. If you reboot after a slow startup, is it still slow?

[chrismurphy]

Originally Posted by lsatenstein

If you reboot after a slow startup, is it still slow?

This is multi-user.target boot, not graphic.target boot. I get a login prompt within about 4 seconds from GRUB timeout, but systemd is still waiting for sendmail to start, back to back reboots. Google searching indicates that this has been an off and on problem with sendmail for some time, for whatever reason. I guess I'm just going to ignore it, but I think it's strange that there's this one service (pair) that's taking almost two orders magnitude longer to start up then the next longest service. Seems obscene.