reassign 786942 systemd,udev retitle 786942 systemd,udev: Long boot-time with systemd-udev-settle thanks
Dear systemd maintainers, I am reassigning this upgrade report to you, in the hopes that you can solve it (or point us in the right direction). Please be sure to notify me explicitly if you reassign it back to "upgrade-reports". Quick summary: * Karl (CC'ed) reported really long boot times (+10 minutes) after upgrade. He had already found a work around by masking the service systemd-udev-settle.service * I advised Karl to purge acpid based on the recommendation in the release-notes plus [archbug#43023], which suggested that acpid with systemd-udev-settle.service caused this (and other) issue(s). * Karl unmasked the service and purged acpid. The boot time is now reasonable, but we still see two services with a questionable long boot time: - systemd-udev-settle.service: 18+ seconds - nut-driver.service: 11+ seconds [archbug#43023]: https://bugs.archlinux.org/task/43023 The following is a quote of Karl's lasted reply to this bug. On 2015-05-27 22:14, Karl Schmidt wrote: > On 05/27/2015 12:18 AM, Niels Thykier wrote: >> On 2015-05-27 04:26, Karl Schmidt wrote: >>> Package: upgrade-reports >>> Severity: important >>> >>> I was able to boot by selecting an older kernel - I then was able to >>> run: >>> # systemctl mask systemd-udev-settle >>> >>> and 3.16.0-4-amd64 now boots. >>> >>> This apparently is related to Intel + ssd (drive details below) >>> >>> I found bread crumbs here - >>> https://bbs.archlinux.org/viewtopic.php?id=189106 >>> >>> But in this case it just hung for over 10min. I would be glad to >>> provide more >>> information if needed and test fixes. Please be specific. >>> >>> [...] >>> >>> >> >> Hi Karl, >> >> Thanks for taking the time to report an upgrade report. >> >> I can see that the archlinux report (link found in the forum posts) >> suggests this is a problem between ACPI and systemd/udev. If you have >> acpid installed, have you tried to uninstall acpid and unmask >> systemd-udev-settle? >> >> Note we have a issue between acpid and logind noted in our release >> notes[1]. > > OK - I did the following > > # systemctl unask systemd-udev-settle > # dpkg --purge acpid > > This lets it boot - but there is now a long delay as seen here from > the top of # systemd-analyze blame > > 18.124s systemd-udev-settle.service > 11.393s nut-driver.service > 4.151s systemd-fsck@dev-md6.service > 3.508s accounts-daemon.service > <snip> > > verses with systemd-udev-settle masked > > 16.651s nut-driver.service > 351ms dphys-swapfile.service > > (the nut-driver should not be so slow either ..) > > My searches on systemd-udev-settle masked tell me it is about "fake > block device storage technology" (in my case mdadm - the raid) > > > I don't really need acpid on this system - it would be nice if it booted > faster like it did. > > Something is still broken - I suspect it has to do with the boot from a > pair of raid-1 solid state drives (acpid gets confused by trying to > monitor the fake block device?) . > > Hope this has been helpful anyway. > > > > -------------------------------------------------------------------------------- > > Link to our website and get free US-48 shipping on your next order. > > Karl Schmidt EMail k...@xtronics.com > Transtronics, Inc. WEB > https://secure.transtronics.com > 3209 West 9th Street Ph (785) 841-3089 > Lawrence, KS 66049 FAX (785) 841-3089 > > Ignorance is not an opinion! > - Dilbert > -------------------------------------------------------------------------------- > > > _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
