udev - next round of udev event order daemon

Here is the next round of udevd/udevsend:

udevsend - If the IPC message we send is not catched by a receiver we fork
the udevd daemon to process this and the following events

udevd - We reorder the events we receive and execute our current udev for
every event. If one or more events are missing, we wait 10 seconds and then go ahead in the queue.
If the queue is empty and we don't receive any event for the next 30 seconds, the daemon exits.
The next incoming event will fork the daemon again.

config - The path's to the executable are specified in udevd.h
Now they are pointing to the current directory only.

I don't like daemons hiding secrets (and mem leaks :)) inside, so I want to try this model. It should be enough logic to get all possible hotplug events executed in the right order.

If no event, then no daemon! So everybody should be happy :)

What do you think? I hope you like the idea.

thanks,
Kay

Here we see:
1. the daemon fork,
2. the udev work,
3. the 10 sec timeout and the skipped events,
4. the udev work,

     ...,

5. and the 30 sec timeout and exit.

EVENTS:

  pim:/home/kay/src/udev.kay# test/udevd_test.sh 
  pim:/home/kay/src/udev.kay# SEQNUM=15 ./udevsend block
  pim:/home/kay/src/udev.kay# SEQNUM=16 ./udevsend block
  pim:/home/kay/src/udev.kay# SEQNUM=17 ./udevsend block
  pim:/home/kay/src/udev.kay# SEQNUM=18 ./udevsend block
  pim:/home/kay/src/udev.kay# SEQNUM=20 ./udevsend block
  pim:/home/kay/src/udev.kay# SEQNUM=21 ./udevsend block

LOG:

  Jan 23 15:35:35 pim udev[11795]: message is still in the ipc queue, starting daemon...
  Jan 23 15:35:35 pim udev[11799]: configured rule in '/etc/udev/udev.rules' at line 19 applied, 'sda' becomes '%k-flash'
  Jan 23 15:35:35 pim udev[11799]: creating device node '/udev/sda-flash'
  Jan 23 15:35:35 pim udev[11800]: creating device node '/udev/sdb'
  Jan 23 15:35:35 pim udev[11804]: creating device node '/udev/sdc'
  Jan 23 15:35:35 pim udev[11805]: removing device node '/udev/sda-flash'
  Jan 23 15:35:35 pim udev[11808]: removing device node '/udev/sdb'
  Jan 23 15:35:35 pim udev[11809]: removing device node '/udev/sdc'
  Jan 23 15:35:45 pim udev[11797]: timeout reached, skip events 7 - 7
  Jan 23 15:35:45 pim udev[11811]: creating device node '/udev/sdb'
  Jan 23 15:35:45 pim udev[11812]: creating device node '/udev/sdc'
  Jan 23 15:36:01 pim udev[11797]: timeout reached, skip events 10 - 14
  Jan 23 15:36:01 pim udev[11814]: creating device node '/udev/sdc'
  Jan 23 15:36:04 pim udev[11816]: creating device node '/udev/sdc'
  Jan 23 15:36:12 pim udev[11818]: creating device node '/udev/sdc'
  Jan 23 15:36:16 pim udev[11820]: creating device node '/udev/sdc'
  Jan 23 15:36:38 pim udev[11797]: timeout reached, skip events 19 - 19
  Jan 23 15:36:38 pim udev[11823]: creating device node '/udev/sdc'
  Jan 23 15:36:38 pim udev[11824]: creating device node '/udev/sdc'
  Jan 23 15:37:08 pim udev[11797]: we have nothing to do, so daemon exits...

diff -Nru a/test/udevd_test.sh b/test/udevd_test.sh
@@ -1,47 +1,52 @@
 #!/bin/bash
 
-# reset udevd, expected sequence number and empty queue
-killall -HUP udevd
+# kill daemon, first event will start it again
+killall udevd
 
-export ACTION=add
-export DEVPATH=/block/sda
+# connect(123) - disconnect(456) - connect(789) sequence of sda/sdb/sdc
 
 export SEQNUM=1
+export ACTION=add
+export DEVPATH=/block/sda
 ./udevsend block
 
 export SEQNUM=2
-./udevsend block
-
-export SEQNUM=3
-./udevsend block
-
-export SEQNUM=5
+export ACTION=add
+export DEVPATH=/block/sdb
 ./udevsend block
 
 export SEQNUM=4
+export ACTION=remove
+export DEVPATH=/block/sda
 ./udevsend block
 
-export SEQNUM=6
+export SEQNUM=3
+export ACTION=add
+export DEVPATH=/block/sdc
 ./udevsend block
 
-export SEQNUM=7
+export SEQNUM=6
+export ACTION=remove
+export DEVPATH=/block/sdc
 ./udevsend block
 
-export SEQNUM=10
+export SEQNUM=5
+export ACTION=remove
+export DEVPATH=/block/sdb
 ./udevsend block
 
-export SEQNUM=9
-#./udevsend block
-
-export SEQNUM=8
+export SEQNUM=7
+export ACTION=add
+export DEVPATH=/block/sda
 #./udevsend block
 
-export SEQNUM=13
-./udevsend block
-
-export SEQNUM=12
+export SEQNUM=9
+export ACTION=add
+export DEVPATH=/block/sdc
 ./udevsend block
 
-export SEQNUM=11
+export SEQNUM=8
+export ACTION=add
+export DEVPATH=/block/sdb
 ./udevsend block
 

diff -Nru a/udevd.h b/udevd.h
@@ -21,9 +21,11 @@
  *
  */
 
-#define HOTPLUGMSGTYPE		44
-#define DEFAULT_EXEC_PROGRAM	"/sbin/udev"
+#define DEFAULT_UDEV_EXEC	"./udev"
+#define DEFAULT_UDEVD_EXEC	"./udevd"
+
 #define IPC_KEY_ID		0
+#define HOTPLUGMSGTYPE		44
 
 
 struct hotplug_msg {

Problem is we end up forking a lot of udevd instances if the system is under load. That's not good :(

I applied this patch, and then added some logic to udevd to only let one instance of it run at a time. It isn't the nicest, but seems to work for now...

Hm, sometimes I still loose an event, I think it's back to the udevsend creating too many udevd instances. Care to look at this?

Is using ipc calls too messy for this? Others have proposed sockets. Would that make the startup logic simpler?

thanks,

greg k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Maybe 190 millisec's are too short?
Hmm, we may also look what pid received the last event and check if this pid is still running. So we prevent forking a new daemon just because of the timeout.

While we wait for the return of the udev exec, we don't get the messages out of the queue. That may cause the problem with the timeout. Do we need a receiver thread? Or fork udev in the background, but then a "remove" may be faster than a "add"?

Yes and no. We notice that we can't connect so there is a better indicator, that there is no daemon. But I think the main problem remains the same. I have less experience with this time critical stuff, so we may try it out, if nobody comes with a better idea?

thanks,
Kay

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel