Uevents weirdness

For you guys who are interested in contemplating the basics of Puppy, this is another one I'm working on, and it is fascinating...

I've had this on my to-do list for a long time. I want to use kernel uevents (hotplug events) to detect insertion/removal and mount/unmount of drives/partitions. This is far more efficient than polling.

I've got it working with Pmount, and it sure does transform Pmount. If I have Pmount running, even minimised in the tray, if I plugin a USB or SD memory, up pops Pmount, updated automatically. Ditto if I remove the memory device. It's brilliant, except that it doesn't work reliably.

If I open a terminal and type this:
# udevadm monitor --kernel

this runs the udevadm utility, which is part of the udev package. The rest of the udev package is not required for the above operation. '--kernel' tells it to print kernel uevents on stdout. Which it does, though there is some strange inconsistency.

I have this in a daemon that is launched at bootup, that has this in it:

udevadm monitor --kernel |
while read ONEUEVENT

and this is where it gets peculiar. I now plug and unplug memory and sometimes the uevents do not occur. Vanished. That's the point I stopped at last night, well early this morning actually.

This morning, after a cup of coffee, looking at it again, I'm wondering if I adjust the priority of the script maybe. I wonder if the script can actually lose some of the data from udevadm -- as that is what seems to be happening, not just a delay. Anyway, with a fresh mind this morning I'll tackle it again.

The idea is that this uevent daemon (I have named it pup_ueventd) can supply update info to Pmount, HotPup and anything else that needs to monitor the drives. Note, inserting a CD does not generate a uevent.

Posted on 8 May 2008, 8:01


Posted on 8 May 2008, 9:18 by dogone
"Thanks for sharing"
Barry. I'm trying to think of another Linux distro in which the principle developer shares so much interesting and educational "stuff". Nothing and no one comes to mind. I find your technical posts fascinating and very educational. They also serve to remind me of what lies under the surface of Linux in general and Puppy in particular. And I believe it is your innate curiosity and drive that makes Puppy so special amongst Linux distros. I may not understand everything you share here, but please keep it coming.

Posted on 8 May 2008, 15:02 by MU
another way
include "/usr/lib/wxbasicscript/basefunctions.inc"


oldstring = thestring

while 1


if oldstring != thestring then
if len(thestring) > len(oldstring) then
print "something changed " & time()

xwin_exec("mut &")
shell("sleep 3")
end if
end if

oldstring = thestring



Posted on 8 May 2008, 24:06 by Bosco Bearbank
another "another way"?
close enough for government work?

thestring=`cat /proc/scsi/scsi`
echo "thestring = $thestring"

while : ; do
thestring=`cat /proc/scsi/scsi`
if [ ${#oldstring} -lt ${#thestring} ]; then
# added length means a new device was detected
sleep 5

Posted on 9 May 2008, 5:02 by Everitt
First off, thanks for a wonderful post, this is a really interesting idea, and one that I'm keen to experiment with myself (the fact that I'm supposed to be revising is of course nothing to do with it.
I'm playing with a perl script to monitor UEVENTS. I'm not fully sure what I'll do with it, but that's not really the point is it? I'm experiencing some weirdness too. ADD evenets come in two parts, one as the device is detected, and one as the partitions are detected. The ting is, the second part is only detected by my perl script (a basic while loop like yours) for the first plug even, after that it's shown along with the 'remove' messageswhen the device is removed... A little odd to say the least!

Posted on 9 May 2008, 8:00 by BarryK
Re: uevent weirdness
Yeah, that's the most weird thing. I racked my brain over that, couldn't see why it is doing that, when my little app 'hotplug2stdout' or 'ueventadm monitor --kernel' if run on their own do not have that weird delay.

For my 'hotplug2stdout', I put in a weird fix -- I put the 'printf' twice in the code -- and lo and behold, piping into my while loop works properly!

Actually, nathan has also expressed an interest in this code, so I'll post just 'hotplug2stdout' for you to look at... ok, it's here: