Hi all,
I've already disabled ntp.service. Thirteen seconds for something I"m not using, but, I knew there would not be a problem disabling it. Now I see that apache.service also is eating up boot time. It clocked in at 23 seconds last boot. But, apache is not installed, and, as far as I can see from apt-cache, there is nothing apache related installed. Both my current installs have apache service enabled, and I'm wondering if this is a bug in the way systemd is set up during an install, or, is there something in siduction that requires the apache.service?
I'm also wondering if anyone else sees this in systemd-analyze blame?
Here's the top of mine:\
# systemd-analyze blame
23.847s apache2.service
11.998s dirmngr.service
9.455s cron.service
6.169s acpi-support.service
4.944s preload.service
4.369s systemd-fsck-root.service
3.456s loadcpufreq.service
3.114s sensord.service
3.110s avahi-daemon.service
3.103s systemd-logind.service
Thanks for advice or comments in advance.
I don't see it on this netbook:
root@tosh205:/# systemd-analyze blame
6.061s nmbd.service
6.020s winbind.service
5.445s samba-ad-dc.service
3.699s wicd.service
1.621s systemd-udev-settle.service
1.600s console-kit-daemon.service
1.413s acpi-fakekey.service
1.303s loadcpufreq.service
1.296s smbd.service
894ms siguibui.service
886ms wpa_supplicant.service
881ms upower.service
874ms avahi-daemon.service
856ms systemd-logind.service
which is a Desperado LXDE system converted from sysv-init. I'll check a more recent installation later and report if it is different.
Apache is a web server. If you're not using it, disable it. And yes, I had quite a few unwanted services starting and had to disable them.
Tim
No apache in my output on any machine.
1.457s systemd-udev-settle.service
1.292s hddtemp.service
1.028s acpi-fakekey.service
896ms nmbd.service
888ms winbind.service
867ms samba-ad-dc.service
835ms teamviewerd.service
759ms acpi-support.service
707ms cron.service
406ms lvm2-activation-early.service
391ms vboxdrv.service
178ms vdr.service
153ms pywwetha.service
129ms sidu-base.service
124ms smbd.service
119ms keyboard-setup.service
117ms udisks2.service
112ms systemd-fsck-root.service
105ms loadcpufreq.service
100ms networking.service
88ms var-cache-swap-swap0.swap
74ms console-setup.service
60ms sysstat.service
57ms nfs-common.service
52ms gpm.service
45ms bootlogs.service
41ms mdadm-raid.service
34ms systemd-udev-trigger.service
34ms systemd-tmpfiles-setup-dev.service
32ms bootchart.service
31ms ntp.service
30ms resolvconf.service
30ms dev-hugepages.mount
28ms irqbalance.service
28ms dev-mqueue.mount
27ms sys-kernel-debug.mount
27ms atop.service
26ms rpcbind.service
25ms media-backup.mount
24ms lm-sensors.service
23ms console-kit-daemon.service
23ms hdparm.service
22ms ifplugd.service
21ms systemd-sysctl.service
20ms ofono.service
20ms keymap.service
17ms console-kit-log-system-start.service
16ms smartmontools.service
15ms mdadm.service
15ms kbd.service
15ms debomatic.service
15ms ddclient.service
14ms motd.service
13ms mbmon.service
12ms kdm.service
12ms saned.service
12ms systemd-tmpfiles-clean.service
12ms rsyslog.service
9ms screen-cleanup.service
9ms alsa-restore.service
8ms polkitd.service
6ms dns-clean.service
6ms pppd-dns.service
5ms systemd-readahead-replay.service
5ms rc-local.service
4ms run-shm.mount
4ms systemd-readahead-collect.service
4ms systemd-user-sessions.service
4ms systemd-update-utmp-runlevel.service
4ms systemd-tmpfiles-setup.service
4ms systemd-udevd.service
3ms systemd-remount-fs.service
3ms home.mount
3ms systemd-random-seed-load.service
3ms qemu-system-x86.service
3ms vboxautostart-service.service
3ms vboxballoonctrl-service.service
3ms systemd-modules-load.service
3ms run-lock.mount
3ms systemd-readahead-done.service
3ms upower.service
3ms glances.service
3ms cpufrequtils.service
2ms udisks.service
2ms tmp.mount
2ms vboxweb-service.service
2ms systemd-logind.service
1ms pulseaudio.service
1ms systemd-journal-flush.service
1ms run-user.mount
1ms sys-fs-fuse-connections.mount
greetz
devil
Quote from: GoinEasy9 on 2014/03/25, 04:27:05
Hi all,
I've already disabled ntp.service. Thirteen seconds for something I"m not using, but, I knew there would not be a problem disabling it.
You really don't need time syncronisation? Your HW-clock does not drift away? Ntp is installed by default ...
QuoteNow I see that apache.service also is eating up boot time. ...
I can understand you want to disable thisone, as you don't have the apache webserver installed.
Thanks for the responses.
So, it seems like having apache2.service enabled is unique to my installs. I've disabled it, and, so far, have not had any problems.
@michaa7 I've never found the need for ntp, local time seems to work just fine. Although, even though I use local time, all my machines switched over to daylight savings time automatically a couple of weeks ago. The only box that didn't was an old Fedora 16 install that runs KDE 4.10.5. I really didn't expect to see that, maybe KDE got a whole lot smarter, but I'm just guessing.
cal@neskaya:~cal: apt-cache policy ntp
ntp:
Installiert: 1:4.2.6.p5+dfsg-3
Installationskandidat: 1:4.2.6.p5+dfsg-3
Versionstabelle:
*** 1:4.2.6.p5+dfsg-3 0
500 http://http.debian.net/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
cal@neskaya:~cal: apt-cache policy ntpdate
ntpdate:
Installiert: (keine)
Installationskandidat: 1:4.2.6.p5+dfsg-3
Versionstabelle:
1:4.2.6.p5+dfsg-3 0
500 http://http.debian.net/debian/ unstable/main amd64 Packages
cal@neskaya:~cal: systemd-analyze blame|grep ntp
619ms ntp.service
I remember a thread a while ago about ntp service slowing systemd startup. The cause was ntpdate, which in fact is not needed for a working ntp service. Apt-get purge ntpdate was the solution as far as I remember.
Greets
ayla
Thanks for the response, ayla. I saw timc's thread today concerning ntpdate and I'm going to follow his instructions to rename it, and it it still shows up in my journalctl, purge it. BTW - disabling ntp.service didn't actually save me time, as you can see from my journalctl output.
goineasy9@siduction64kdefx:~$ journalctl -b | grep ntpdate
Mar 26 16:28:17 siduction64kdefx ntpdate[1152]: Can't find host 0.debian.pool.ntp.org: Name or service not known (-2)
Mar 26 16:28:17 siduction64kdefx ntpdate[1152]: Can't find host 1.debian.pool.ntp.org: Name or service not known (-2)
Mar 26 16:28:17 siduction64kdefx ntpdate[1152]: Can't find host 2.debian.pool.ntp.org: Name or service not known (-2)
Mar 26 16:28:17 siduction64kdefx ntpdate[1152]: Can't find host 3.debian.pool.ntp.org: Name or service not known (-2)
Mar 26 16:28:17 siduction64kdefx ntpdate[1152]: no servers can be used, exiting
Mar 26 21:28:12 siduction64kdefx ntpdate[2957]: step time server 208.87.104.40 offset 17965.831685 sec
Since apache wasn't installed, removing the service saved me some time. My preload.service, on the other hand, only uses 4.5 seconds so, I'm wondering how much it will help to delete /var/lib/preload/preload.state. I'm going to keep looking at playing with services.
BTW - Timc's other thread: http://forum.siduction.org/index.php?topic=4053.0 (http://forum.siduction.org/index.php?topic=4053.0)
Edit: WOW, very much faster boot. My preload only went from 4.5 to 3.2, but, hey, every little bit helps. Renaming ntpdate-debian was the real helper.
BTW - Something else I noticed. It seems that even though apache2 was never installed, I have an /etc/apache2 folder. That, and the apache2.service showing up at boot, is still a puzzle to me.
Quote from: GoinEasy9My preload only went from 4.5 to 3.2, but, hey, every little bit helps.
A post from melmarker about preload or not preload may be of interest. Seems one have to pay a price for a little faster bootup.
http://forum.siduction.org/index.php?topic=4232.msg35516#msg35516greets
ayla
Thanks ayla. Today preload.service is up to 7.73s, so, I don't think letting it rebuild is having any downside, except for an additional few seconds of boot time. In fact, most posts on various mailing lists endorse clearing the preload.state to solve problems. I don't have any intentions of disabling preload, so, I'm just going to keep any eye on it.
Thanks again.