Interaction of udev with the init subsystem
Hi,
I'm maintaining the udev package for Pardus, a GNU/Linux distribution mainly developed in Turkey.
After doing some investigations of the startup time on our distribution, I've figured that udev related invocations takes a lot of time.
1) The startup of the daemon is quick enough, no problem here,
2) The first trigger+settle takes ~4.5 seconds to complete.
We're currently using udev-126 but I also tried 137, and the performance is quite the same.
I wonder what are the points that a distribution packager/maintainer should consider when starting/stopping udev for having the best startup time.
My second question is about the orphaned rule files left in /dev/.udev after triggering the event processing on a read-only root filesystem. I'm succesfully collecting those rules, moving them into /etc/udev/rules.d and recalling trigger after mounting the root filesystem read-write. If I don't retrigger,
no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains a media during boot. Retriggering here takes ~0.11 seconds.
It would be very nice to have a detailed documentation for udev beside rule writing stuff.
Thanks,
Signature · 2 lines
Ozan Çağlayan <ozan_at_pardus.org.tr>
Quoted 5 lines · Ozan Çağlayan
Hi,
I'm maintaining the udev package for Pardus, a GNU/Linux distribution mainly developed in Turkey.
Quoted 8 lines
After doing some investigations of the startup time on our distribution, I've figured that udev related invocations takes a lot of time.
1) The startup of the daemon is quick enough, no problem here,
2) The first trigger+settle takes ~4.5 seconds to complete.We're currently using udev-126 but I also tried 137, and the performance is quite the same.
It's the modprobe stuff that is taking most of the time, right? That's not udev.
Quoted 11 lines
I wonder what are the points that a distribution packager/maintainer should consider when starting/stopping udev for having the best startup time.
My second question is about the orphaned rule files left in
/dev/.udevafter triggering the event processing on a read-only root filesystem. I'm succesfully collecting those rules, moving them into/etc/udev/rules.dand recalling trigger after mounting the root filesystem read-write. If I don't retrigger,
no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains a media during boot. Retriggering here takes ~0.11 seconds.It would be very nice to have a detailed documentation for udev beside rule writing stuff.
Patches are always gladly welcome :)
thanks,
greg k-h
Quoted 8 lines · Ozan Çağlayan
I'm maintaining the udev package for Pardus, a GNU/Linux distribution mainly developed in Turkey.
After doing some investigations of the startup time on our distribution, I've figured that udev related invocations takes a lot of time.
1) The startup of the daemon is quick enough, no problem here,
2) The first trigger+settle takes ~4.5 seconds to complete.
Run "udevadm monitor" during that time, and check which of the events is blocking the "settle" for that long.
Quoted 8 lines
My second question is about the orphaned rule files left in
/dev/.udevafter triggering the event processing on a read-only root filesystem. I'm succesfully collecting those rules, moving them into/etc/udev/rules.dand recalling trigger after mounting the root filesystem read-write. If I don't retrigger,
no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains a media during boot. Retriggering here takes ~0.11 seconds.It would be very nice to have a detailed documentation for udev beside rule writing stuff.
I don't think there is much more you need to do, than you do already.
It very much depends on the specific distro setup, like some mount the rootfs rw, so there are no rules to move around, and a single coldplug run does all needed work.
Some systems support things like /usr on a different disk, which has its very own set of problems, which will likely get harder over time to support, because we got more and more udev consumers which rely on /usr to be always around, and so on ...
Kay