[systemd-devel] udev took too long to start

[microcai]

于 2011年05月20日 12:10, microcai 写道:
> 于 2011年05月20日 18:39, Lennart Poettering 写道:
>> On Fri, 20.05.11 17:40, Chen Jie (chenj at lemote.com) wrote:
>>
>>> 2011/5/19 Chen Jie <chenj at lemote.com>:
>>>> 2011/5/18 Kay Sievers <kay.sievers at vrfy.org>:
>>>>>
>>>>> Completely different! That's an Intel Core Duo 1.4 GHz laptop:
>>>>>  systemd-analyze blame | grep udev
>>>>>  87ms udev-trigger.service
>>>>>  13ms udev.service
>>>> I updated systemd(to v26) and udev(to 168), still got ~1s startup time
>>>> of udev.service plus udev-trigger.service.
>>>>
>>>> May be some distribution added udev rules cause this? I'll do a
>>>> bootchart to see the detail.
>>> See the attachment.
>>
>> There are a ton of things udev seems to be calling. A lot of it doesn't
>> look right. i.e. systemctl being called from udev doesn't look
>> right. And ps? grep? hdparm?? sync??? alsa-utils looks wrong too? mount?
>>
>> The exim script looks really borked too. And the mkdir/rm sprinkled
>> around dbus/rsyslog is suspicous too.
>>
>> I think the distro you are using is a bit too hack-happy... Your
>> downstream udev maintainers really should spend some time on cleaning up
>> those udev rules. Upstream udev doesn't ship that nonsense!
>>
>> Lennart
>>
> 
> 
> 
> Thanks ALL ~~~
> 
> My system now boots faster ~~~
> 
> See my new system boot time as attachment.
> 
> cairo.SVGSurface have problem here, so I change it to PDFSurface.
> 
> 
> 

Wait a second here!

udev.service slow down again~~~


Now I've full relized that, the problem is fsck-root.service.

udev.service stay idle as soon as fsck-root.service exit.

It is fsck-root.service that took so long to do the job.

Seems fsck always did a full check on /. Does systemd have a bug when
umount / @ shutdown?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110520/046d2261/attachment.pgp>