Re: waiting for an unknown set of udev /dev entries to complete

[Kay Sievers <kay.sievers@vrfy.org>]

On Fri, Nov 18, 2005 at 02:30:45PM -0800, Patrick Mansfield wrote:
> Any ideas on the best way to wait for udev to finish handling a set of
> hotplug events?

I have changes in my udev tree, to export the udevd event queue. It
will probably be in 076 - if it works as expected. For every queued
or running event, a symlink in /dev/.udev/queue/ is created and removed
after the udev event process has exited. For all failing udev events,
the queue files are moved to /dev/.udev/failed.

We want this for coldplug after bootup, to try to trigger failed events
again, if requirements are fulfilled only at a later stage of the boot
process.

  kay@pim:~> tree /dev/.udev
  /dev/.udev
  |-- db
  |   |-- block@sda
  |   |-- block@sda@sda1
  ...
  |-- failed
  |   `-- class@net@sit0 -> /sys/class/net/sit0
  `-- queue
      |-- block@sda -> /sys/block/sda
      |-- class@input@input0 -> /sys/class/input/input0
  ...

> That is, if I load a module or otherwise generate an unknown number of
> hotplug events for a single action or event - like a modprobe of a scsi
> HBA or even modprobe sd_mod - how can I tell when all hotplug events have
> been handled and /dev entries created?

You should be able to look for /dev/.udev/queue/*block*, and see if
there are events still running.

> I'm not asking how to wait for a specific /dev entry or a single hotplug
> event for a particular device.

Sure.

> I was thinking of:
> 
> 1) (I'm looking for scsi block devices) Waiting for an equal number of
> /dev/sd* nodes to show up as is found under /sys/block/sd* and
> /sys/block/sd*/sd*. Is specific, and failure modes are kind of ugly (a
> timeout could be used, but if hotplug is really slow and is making
> progress you don't want to stop waiting).
> 
> 2) Waiting for all hotplug processes to finish.  This is more general
> purpose (not scsi or block specific, but doesn't handle children of
> kernel.hotplug that are not named the same (at least my script below has
> this problem).

You may not detach from the event process for short living programs,
that will leave the event in the queue. If you need to do really complicated
things, you may need to synchronize the events yourself at a higher level.

> I can't think of a way to handle this in a udev rule, since those are too
> general (i.e. they don't know what the last event should be).

Yes, there is no such logic.

> -------------------------------------------
> #! /bin/bash
> 
> # load modules, iscsi login, etc. here (does NOT have to be run in the
> # background)
> #
> # I am using:
> # ~patman/iscsi/open-iscsi/usr/iscsiadm  -m node --record 22698c --login
> 
> count=$(ls -d /sys/block/sd* /sys/block/sd*/sd* | wc -l)
> devsd=$(ls /dev/sd* | wc -l)
> while [[ ${devsd} -lt ${count} ]]
> do
> 	echo $(date) waiting count ${count} devsd ${devsd}
> 	sleep 1
> 	devsd=$(ls /dev/sd* | wc -l)
> done
> 
> -------------------------------------------

Should work fine with the exported event queue.

> And for 2): Again, could fail if the hotplug handler forks and returns,
> leaving its child running. Shell script like:
> 
> -------------------------------------------
> 
> #! /bin/bash
> 
> # load modules, iscsi login etc here
> # ~patman/iscsi/open-iscsi/usr/iscsiadm  -m node --record 22698c --login
> 
> hotplug=$(sysctl kernel.hotplug)
> while /sbin/pidof -s ${hotplug} > /dev/null 2>&1
> do
> 	echo waiting $(date) ...
> 	sleep 1
> done
> 
> -------------------------------------------

There is no "kernel.hotplug" that runs anything. Usually it's "udevsend",
which just passes the event to the udev daemon. On SUSE it's disabled
completely for a long time.
The udev daemon listens to netlink and /sbin/hotplug does almost nothing
on all recent systems. It is only used for the "input" system which lacked
driver core support until 2.6.15.

> More background:
> 
> Module loads should check this during boot and install, but I haven't
> found such checks (so far, I see some stuff in suse network code but that
> is for networks). Most cases will just work for a small number of disks
> and a sufficient interval between module load and mounting (for boot) or
> use (for an install) of the intended device.

What do you mean with: "Module loads should check this" in this case?

> With current FC rawhide/devel, I am working on iscsi install, and had udev
> "error" logging enabled on a medium speed dual processor system. So the
> scripts are very slow, and the partition setup code is being run right
> after iscsi scan (really discovery/login and then scan) and it does not
> see all the devices (and I probably have some bugs still). 

Hmm, care to explain that better, I don't really understand...

> It takes over a second per scsi sd, and I have about 60 of them.

But these are not serialized, are they?

Best,
Kay


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel