when startup delays become bugs

Eric Sandeen sandeen at redhat.com
Fri May 17 21:53:15 UTC 2013


On 5/17/13 3:38 PM, Ric Wheeler wrote:
> On 05/16/2013 02:39 PM, Lennart Poettering wrote:
>> On Thu, 16.05.13 12:20, Chris Murphy (lists at colorremedies.com) wrote:
>>
>>> There have been no crashes, so ext4 doesn't need fsck on every boot:
>>>
>>>            4.051s systemd-fsck-root.service
>>>             515ms
>>>             systemd-fsck at dev-disk-by\x2duuid-09c66d01\x2d8126\x2d39c2\x2db7b8\x2d25f14cbd35af.service
>> Well, but only fsck itself knows that and can determine this from the
>> superblock. Hence we have to start it first and it will then exit
>> quickly if the fs wasn't dirty.
>>
>> Note that these times might be misleading: if fsck takes this long to
>> check the superblock and exit this might be a result of something else
>> which runs in parallel monopolizing CPU or IO (for example readahead),
>> and might not actually be fsck's own fault.
> 
> We really should not need to run fsck on boot unless the mount fails. Might save some time at the cost of a bit of extra complexity?

well, ext[34]a are special little snowflakes.  ;)

Since forever, we've called fsck on boot, and e2fsck replays the log in userspace if needed.  If the fs isn't marked as having encountered an error during the previous mount (or, historically, having had too many mounts or too much time since last fsck), then nothing else happens.

It shouldn't take a whole ton of time, but could, depending on whether the log was dirty, then the size of the log and speed of the disk I suppose.

When it took 4s above, was that a from a clean reboot (i.e. was the journal dirty?)

-Eric

> Ric
> 
>>
>>> and no oops, so this seems unnecessary:
>>>
>>>            1.092s abrt-uefioops.service
>> https://bugzilla.redhat.com/show_bug.cgi?id=963182
>>
>>> and I'm not using LVM so these seem unnecessary:
>>>
>>>
>>>            2.783s lvm2-monitor.service
>>>             489ms systemd-udev-settle.service
>>>              15ms lvm2-lvmetad.service
>>>
>>> How do I determine what component to file a bug against? I guess I have to find the package that caused these .service files to be installed?
>> $ repoquery --qf="%{sourcerpm}" --whatprovides '*/lib/systemd/system/lvm2-monitor.service'
>> lvm2-2.02.98-8.fc19.src.rpm
>>
>> Please file a bug against the "lvm2" package. And make sure to add it to:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=963210
>>
>> Hmm, on your machine, what does "systemctl show -p WantedBy -p
>> RequiredBy systemd-udev-settle.service" show? This will tell us which
>> package is actually responsible for pulling in
>> systemd-udev-settle.service.
>>
>> Thanks!
>>
>> Lennart
>>
> 



More information about the devel mailing list