Re: much longer boot time with jessie
Quoting Sven Hartge (s...@svenhartge.de): > David Wright wrote: > > > $ systemd-analyze blame > > 36.727s wicd.service > > 22.102s binfmt-support.service > > 20.789s alsa-restore.service > > 20.618s lm-sensors.service > > 20.565s systemd-logind.service > > 20.471s rsyslog.service > > 20.468s rc-local.service > > 20.465s systemd-user-sessions.service > > 20.462s apmd.service > > 20.461s virtualbox.service > > 20.461s loadcpufreq.service > > 20.460s gpm.service > > 20.135s bluetooth.service > > 19.730s exim4.service > > 11.922s timidity.service > > This is very very strange. But I notice a common pattern among those > service. Nearly all take about 20.4 seconds to start. My guess is that bluetooth is the first service in that group (though it wasn't when acpid was still present). Bluetooth is also the first emitter of a boot message after a long pause just after d-bus starts. So it may be that a number of processes are waiting on d-bus. After removing acpid etc, these services disappeared: acpi-support.service console-kit-daemon.service console-kit-log-system-start.service rtkit-daemon.service systemd-rfkill@rfkill4.service systemd-rfkill@rfkill5.service systemd-suspend.service systemd-tmpfiles-clean.service and the timings of various services changed markedly: ModemManager 88s -> 43/47s, ntp 47 -> 8/6s, user@1000 8 -> 1s were the big winners, but that clump at 20s used to be around 15s. wicd slowed by a larger amount. Removing modemmanager removed: ModemManager.service polkitd.service but the relative timings remained very similar. > To compare, here is a list of the top services from my workstation: > > 8.540s systemd-journal-flush.service > 4.379s dev-md0.device > 4.359s dev-dm\x2d0.device > 4.063s accounts-daemon.service > 3.329s munin-node.service > 3.041s systemd-udev-settle.service > 2.806s teamviewerd.service > 2.743s binfmt-support.service > 2.391s mdadm-raid.service > 2.084s systemd-logind.service > 2.010s loadcpufreq.service > 1.987s irqbalance.service > 1.973s rsyslog.service > 1.953s systemd-user-sessions.service > 1.942s timidity.service > 1.940s lm-sensors.service > 1.648s schroot.service > 1.639s lightdm.service > 1.598s avahi-daemon.service > 1.408s mcelog.service > 1.354s sensord.service > 1.330s systemd-cryptsetup@cswap.service > 1.224s dirmngr.service > 1.168s autofs.service > 1.109s virtualbox.service > > (systemd-journal-flush takes so long, because is set to persistent and > has to flush the journal to a read HDD instead of to /run, which is a > tmpfs.) > > As you can see, most services start in under 3 seconds. The whole > startup from kernel to lightdm takes 29.5 seconds: > > Startup finished in 5.721s (kernel) + 23.808s (userspace) = 29.529s Startup finished in 5.630s (kernel) + 1min 21.711s (userspace) = 1min 27.341s I'm guessing that waiting for the disk gets charged to userspace rather than the kernel? > > I've tried to analyse the Login-BashPrompt time of 30-34 secs. > > I added set -v to the start of .bash_profile and the end of .bashrc, > > and set +v to the start of .bashrc and the end of .bash_profile, > > ie excluding tracing .bashrc because it lists every function > > as they are defined. > > > What I discovered is that .bash_profile is reached 16 seconds after > > "You have new mail." and that a function which copies a lot of my > > startup files to /tmp/.my-startups/ takes over 15 seconds to run. > > (The disk activity light is lit through the entire boot/login process > > and beyond.) > > What is that "my startup files"? This must be something special and home > brewn on your system, right? I guess this special function runs for > every init-script and causing the delay of your boot. Could you please > disable whatever does this "copying of my startup files" and try again? The startup files belong to user 1000 (me) and so are not involved with getting to the Login prompt. The copying process only runs from my .bash_profile and only if the target directory does not exist, ie only once per boot. It's significance here is that the copying has to compete with the frenetic disk activity going on at the time. I should point out that when I type my username to the first Login prompt, the Password prompt takes between 3 and 8 seconds to appear. In wheezy, the delay is a fraction of a second. (Sometimes wheezy misses the first character of my password at the rate I type, something that never happens on all my desktop machines.) When wheezy boots, the disk activity light goes out when the Login prompt appears. It then flickers a few times (for anything up to a second e
Re: much longer boot time with jessie
David Wright wrote: > $ systemd-analyze blame > 36.727s wicd.service > 22.102s binfmt-support.service > 20.789s alsa-restore.service > 20.618s lm-sensors.service > 20.565s systemd-logind.service > 20.471s rsyslog.service > 20.468s rc-local.service > 20.465s systemd-user-sessions.service > 20.462s apmd.service > 20.461s virtualbox.service > 20.461s loadcpufreq.service > 20.460s gpm.service > 20.135s bluetooth.service > 19.730s exim4.service > 11.922s timidity.service This is very very strange. But I notice a common pattern among those service. Nearly all take about 20.4 seconds to start. To compare, here is a list of the top services from my workstation: 8.540s systemd-journal-flush.service 4.379s dev-md0.device 4.359s dev-dm\x2d0.device 4.063s accounts-daemon.service 3.329s munin-node.service 3.041s systemd-udev-settle.service 2.806s teamviewerd.service 2.743s binfmt-support.service 2.391s mdadm-raid.service 2.084s systemd-logind.service 2.010s loadcpufreq.service 1.987s irqbalance.service 1.973s rsyslog.service 1.953s systemd-user-sessions.service 1.942s timidity.service 1.940s lm-sensors.service 1.648s schroot.service 1.639s lightdm.service 1.598s avahi-daemon.service 1.408s mcelog.service 1.354s sensord.service 1.330s systemd-cryptsetup@cswap.service 1.224s dirmngr.service 1.168s autofs.service 1.109s virtualbox.service (systemd-journal-flush takes so long, because is set to persistent and has to flush the journal to a read HDD instead of to /run, which is a tmpfs.) As you can see, most services start in under 3 seconds. The whole startup from kernel to lightdm takes 29.5 seconds: Startup finished in 5.721s (kernel) + 23.808s (userspace) = 29.529s > I've tried to analyse the Login-BashPrompt time of 30-34 secs. > I added set -v to the start of .bash_profile and the end of .bashrc, > and set +v to the start of .bashrc and the end of .bash_profile, > ie excluding tracing .bashrc because it lists every function > as they are defined. > What I discovered is that .bash_profile is reached 16 seconds after > "You have new mail." and that a function which copies a lot of my > startup files to /tmp/.my-startups/ takes over 15 seconds to run. > (The disk activity light is lit through the entire boot/login process > and beyond.) What is that "my startup files"? This must be something special and home brewn on your system, right? I guess this special function runs for every init-script and causing the delay of your boot. Could you please disable whatever does this "copying of my startup files" and try again? Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dblt15l8b...@mids.svenhartge.de
Re: much longer boot time with jessie
Quoting Michael Biebl (bi...@debian.org): > Am 04.06.2015 um 06:59 schrieb David Wright: > > $ systemd-analyze blame > > 1min 13.144s acpi-support.service > > Can you please try and uninstall and purge > the following packages (not typically needed with jessie anyway) > > acpid > acpi-support-base > acpi-support > consolekit I've purged (in three tranches): [REMOVE, NOT USED] acpi-fakekey:i386 [REMOVE, NOT USED] libck-connector0:i386 [REMOVE, NOT USED] libpam-ck-connector:i386 [REMOVE] acpi-support:i386 [REMOVE] acpi-support-base:i386 [REMOVE] acpid:i386 [REMOVE] avahi-autoipd:i386 [REMOVE] avahi-daemon:i386 [REMOVE, NOT USED] libavahi-core7:i386 [REMOVE, NOT USED] libdaemon0:i386 [REMOVE] modemmanager:i386 but the resulting timings are not encouraging: 74 to login, 30 to bash prompt, 62 for X. After the third tranche: $ systemd-analyze blame 36.727s wicd.service 22.102s binfmt-support.service 20.789s alsa-restore.service 20.618s lm-sensors.service 20.565s systemd-logind.service 20.471s rsyslog.service 20.468s rc-local.service 20.465s systemd-user-sessions.service 20.462s apmd.service 20.461s virtualbox.service 20.461s loadcpufreq.service 20.460s gpm.service 20.135s bluetooth.service 19.730s exim4.service 11.922s timidity.service 6.523s ntp.service 5.925s colord.service 4.376s kbd.service 4.109s networking.service 3.461s systemd-tmpfiles-setup-dev.service 3.400s systemd-modules-load.service 3.257s systemd-fsck@dev-disk-by\x2dlabel-john03.service 3.215s keyboard-setup.service 3.027s systemd-fsck@dev-disk-by\x2dlabel-john02.service 2.947s irqbalance.service 2.775s nfs-common.service 2.600s systemd-tmpfiles-setup.service 2.215s rpcbind.service 1.900s dev-hugepages.mount 1.808s dev-mqueue.mount 1.788s resolvconf.service 1.773s hdparm.service 1.753s westw.mount 1.738s sys-kernel-debug.mount 1.428s systemd-journal-flush.service 1.420s systemd-setup-dgram-qlen.service 1.226s user@1000.service 1.167s cpufrequtils.service 1.145s systemd-udev-trigger.service 1.013s aumix.service 927ms gdomap.service 828ms saned.service 658ms kmod-static-nodes.service 521ms dev-disk-by\x2dlabel-john04.swap 486ms systemd-update-utmp.service 381ms systemd-udevd.service 366ms systemd-backlight@backlight:intel_backlight.service 310ms systemd-rfkill@rfkill2.service 310ms systemd-rfkill@rfkill1.service 310ms systemd-rfkill@rfkill0.service 287ms systemd-sysctl.service 241ms home.mount 218ms systemd-backlight@backlight:dell_backlight.service 195ms clamav-daemon.socket 178ms systemd-random-seed.service 108ms console-setup.service 65ms systemd-remount-fs.service 52ms systemd-rfkill@rfkill3.service 47ms udev-finish.service 18ms proc-sys-fs-binfmt_misc.mount 8ms systemd-update-utmp-runlevel.service 3ms sys-fs-fuse-connections.mount $ 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 17.390s └─multi-user.target @1min 17.390s └─exim4.service @57.659s +19.730s └─clamav-daemon.service @57.652s └─basic.target @36.880s └─sockets.target @36.877s └─clamav-daemon.socket @36.678s +195ms └─sysinit.target @36.671s └─nfs-common.service @33.893s +2.775s └─rpcbind.target @33.886s └─rpcbind.service @31.667s +2.215s └─network-online.target @31.661s └─network.target @31.657s └─networking.service @27.545s +4.109s └─local-fs.target @27.522s └─run-rpc_pipefs.mount @36.015s └─local-fs-pre.target @12.226s └─systemd-remount-fs.service @12.152s +65ms └─keyboard-setup.service @8.928s +3.215s └─systemd-udevd.service @8.537s +381ms └─systemd-tmpfiles-setup-dev.service @5.073s +3.461s └─kmod-static-nodes.service @4.412s +658ms └─system.slice @4.406s └─-.slice @4.405s I've tried to analyse the Login-BashPrompt time of 30-34 secs. I added set -v to the start of .bash_profile and the end of
Re: much longer boot time with jessie
Am 04.06.2015 um 06:59 schrieb David Wright: > $ systemd-analyze blame > 1min 13.144s acpi-support.service Can you please try and uninstall and purge the following packages (not typically needed with jessie anyway) acpid acpi-support-base acpi-support consolekit and report back if that makes a difference -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: much longer boot time with jessie
Quoting Fekete Tamás (fek...@gmail.com): >>> I have 7 years old computer with wheezy installed on it. Temporarly or not I >>> decided to keep this older version of Debian, because I upgraded to jessie >>> and >>> the boot time became extremey slower. To represent this with numbers: when >>> grub >>> finished with countdown, took 52 seconds to boot into GDM. >>> In wheezy it tooks only 30 sec (which is completely normal I think) with the >>> same conditions. My experience is similar on this 7 year old laptop. Typical timings: jessie wheezy 1 Grub to Login Prompt82 47 2 Login Prompt to VC Bash Prompt 33 6 3 Bash Command to X fully up 62 16 2 and 3 are faster if repeated after all the startup disk activity has subsided. 1 usually takes an infinite time if the module binfmt_misc is not loaded from /etc/modules. (See https://lists.debian.org/debian-user/2015/05/msg01060.html and follow the In-reply-to or References links. > So, firstly the slowlyness was not because of the first boot (because I tried > more than 10times) > Secondly, I can not say how the system would act for commands given by Michael > (because > I moved back to wheezy) Here's the output for this laptop: $ systemd-analyze blame 1min 27.935s ModemManager.service 1min 13.144s acpi-support.service 52.112s avahi-daemon.service 46.983s ntp.service 26.242s wicd.service 20.986s exim4.service 19.930s timidity.service 17.381s console-kit-daemon.service 16.372s binfmt-support.service 16.274s alsa-restore.service 16.273s console-kit-log-system-start.service 15.918s bluetooth.service 15.663s lm-sensors.service 15.303s systemd-logind.service 15.206s rc-local.service 15.202s systemd-user-sessions.service 15.200s apmd.service 15.199s rsyslog.service 15.199s virtualbox.service 15.199s loadcpufreq.service 15.198s gpm.service 11.174s colord.service 9.694s aumix.service 8.227s user@1000.service 7.388s polkitd.service 7.365s systemd-suspend.service 4.271s keyboard-setup.service 3.677s systemd-fsck@dev-disk-by\x2dlabel-john03.service 3.674s networking.service 3.618s kbd.service 2.958s nfs-common.service 2.916s systemd-modules-load.service 2.548s irqbalance.service 2.469s systemd-tmpfiles-setup-dev.service 2.342s resolvconf.service 2.199s systemd-tmpfiles-setup.service 2.019s systemd-setup-dgram-qlen.service 2.015s dev-hugepages.mount 1.926s dev-mqueue.mount 1.849s systemd-fsck@dev-disk-by\x2dlabel-john02.service 1.841s sys-kernel-debug.mount 1.829s hdparm.service 1.475s rpcbind.service 1.437s systemd-udev-trigger.service 1.415s gdomap.service 1.233s saned.service 1.164s cpufrequtils.service 868ms dev-disk-by\x2dlabel-john04.swap 654ms westw.mount 640ms kmod-static-nodes.service 545ms systemd-update-utmp.service 528ms systemd-udevd.service 512ms systemd-remount-fs.service 431ms rtkit-daemon.service 424ms systemd-backlight@backlight:intel_backlight.service 312ms systemd-rfkill@rfkill1.service 305ms systemd-rfkill@rfkill0.service 286ms systemd-sysctl.service 286ms systemd-rfkill@rfkill4.service 274ms systemd-rfkill@rfkill3.service 243ms systemd-tmpfiles-clean.service 237ms systemd-backlight@backlight:dell_backlight.service 195ms systemd-rfkill@rfkill2.service 120ms console-setup.service 109ms clamav-daemon.socket 95ms systemd-random-seed.service 91ms udev-finish.service 42ms home.mount 19ms proc-sys-fs-binfmt_misc.mount 12ms systemd-rfkill@rfkill5.service 12ms systemd-journal-flush.service 11ms systemd-update-utmp-runlevel.service 5ms sys-fs-fuse-connections.mount $ 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 @2min 6.738s └─multi-user.target @2min 6.738s └─acpi-support.service @53.593s +1min 13.144s [in RED] └─basic.target @37.647s └─sockets.target @37.643s └─clamav-daemon.socket @37.530s +109ms [in RED] └─sysinit.target @37.517s └─systemd-journald.service @1min 50.051s └─syslog.socket @6.791s └─systemd-setup-dgram-qlen.service @4.768s +2.019s [in RED] └─system.slice @4.766s └─-.slic
Re: much longer boot time with jessie
Fekete Tamás wrote on 06/01/2015 11:02 AM: > The only thing I can add to this topic that the problem came not because of > a > bad apt-get dist-upgrade, because boot was slowly even if I installed a > completely new jessie. > > Based on your answers, it seems my problem is an exception and not the rule. > But it seems something is not okay with the new jessie, that's sure. > An additional datum that might help someone: I experienced the same thing on Kubuntu. But when I installed jessie on the hardware, this problem went away. Doc -- Web: http://www.sff.net/people/N7DR signature.asc Description: OpenPGP digital signature
Re: much longer boot time with jessie
Hello! I was over of the 10'th reboot, when I gave up and reinstalled wheezy (I was unable to modify the starting processes as well. I wanted to do it, because I hate starting into gdm3, and the system was not able to handle update-rc.d -f gdm3 remove command. I mean gdm3 was disappeared from rc.x directories, but systemd was still boot me into gdm3.) So, firstly the slowlyness was not because of the first boot (because I tried more than 10times) Secondly, I can not say how the system would act for commands given by Michael (because I moved back to wheezy) The only thing I can add to this topic that the problem came not because of a bad apt-get dist-upgrade, because boot was slowly even if I installed a completely new jessie. Based on your answers, it seems my problem is an exception and not the rule. But it seems something is not okay with the new jessie, that's sure. 2015-05-31 23:54 GMT+02:00 Michael Biebl : > Am 31.05.2015 um 21:29 schrieb Fekete Tamás: > > Hy everyone! > > > > I have 7 years old computer with wheezy installed on it. Temporarly or > not > > I decided to keep this older version of Debian, because I upgraded to > > jessie and the boot time became extremey slower. To represent this with > > numbers: when grub finished with countdown, took 52 seconds to boot into > > GDM. > > In wheezy it tooks only 30 sec (which is completely normal I think) with > > the same conditions. > > > > Same conditions. Except two. (Sorry for those who believe of the success > of > > systemd.) I have to suspect systemd and new Gnome as well. > > > > What does "systemd-analyze blame" and "systemd-analyze critical-chain" say? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Re: much longer boot time with jessie
Am 31.05.2015 um 21:29 schrieb Fekete Tamás: > Hy everyone! > > I have 7 years old computer with wheezy installed on it. Temporarly or not > I decided to keep this older version of Debian, because I upgraded to > jessie and the boot time became extremey slower. To represent this with > numbers: when grub finished with countdown, took 52 seconds to boot into > GDM. > In wheezy it tooks only 30 sec (which is completely normal I think) with > the same conditions. > > Same conditions. Except two. (Sorry for those who believe of the success of > systemd.) I have to suspect systemd and new Gnome as well. > What does "systemd-analyze blame" and "systemd-analyze critical-chain" say? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: much longer boot time with jessie
On 05/31/2015 03:29 PM, Fekete Tamás wrote: Hy everyone! I have 7 years old computer with wheezy installed on it. Temporarly or not I decided to keep this older version of Debian, because I upgraded to jessie and the boot time became extremey slower. To represent this with numbers: when grub finished with countdown, took 52 seconds to boot into GDM. In wheezy it tooks only 30 sec (which is completely normal I think) with the same conditions. Same conditions. Except two. (Sorry for those who believe of the success of systemd.) I have to suspect systemd and new Gnome as well. Has anyone also experienced this longer boot time, or am I the only one? I think the first time you boot Jessie, there is some sorting out going on in the background. The second boot is speedier. Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/556b62c4.1050...@gmail.com
much longer boot time with jessie
Hy everyone! I have 7 years old computer with wheezy installed on it. Temporarly or not I decided to keep this older version of Debian, because I upgraded to jessie and the boot time became extremey slower. To represent this with numbers: when grub finished with countdown, took 52 seconds to boot into GDM. In wheezy it tooks only 30 sec (which is completely normal I think) with the same conditions. Same conditions. Except two. (Sorry for those who believe of the success of systemd.) I have to suspect systemd and new Gnome as well. Has anyone also experienced this longer boot time, or am I the only one?
