new pup_event_frontend

/sbin/pup_event_frontend_d is a daemon that is started when X starts, in /root/.xinitrc. It was a big ponderous script.

I have reorganised it into a modular form, with files in /usr/local/pup_event.

/sbin/pup_event_frontend_d is now a wrapper, that just launches /usr/local/pup_event/pup_event_frontend_d. The latter is a binary executable written in BaCon.

The source /usr/local/pup_event/pup_event_frontend_d.bac requires BaCon version 2.1.7 or later to compile.

The new daemon creates a netlink socket to receive kernel uevents, and when a drive add or remove is detected, calls script frontend_change.

The daemon calls frontend_timeout every four seconds to perform various housekeeping.

On my newest laptop, the kernel detects when an optical media is inserted/removed, so is handled in frontend_change.
Unfortunately, the kernel (3.2.44) does not detect optical media insert/remove in my older laptop (2006 vintage), so I have to poll in frontend_timeout.

Back when I first developed pup_event_frontend_d, mid-2008, the kernel did not reliably detect SD-card insert/remove, but that seems to have been fixed, testing on my older laptop.
Note, my latest laptop has an internal USB interface for the SD-card socket, whereas my older laptop has a true SD-card interface (and devices show up as /dev/mmcblk*.

I have compiled an x86 pup_event_frontend_d, which is in Woof, next I have to do same for ARM. I also need to upgrade the BaCon PETs to version 2.1.7 or later.

Woof commit:

A note to end-users:
All of the above will be invisible to users, except that it will hopefully make things a bit more snappy.

The daemon uses very little CPU time, except when it calls frontend_timeout -- and it is on my to-do-list to move more from the latter into the former, to make things even more snappy.

I spent all day today testing, so hopefully no bugs got through.

Posted on 10 Jun 2013, 19:33


Posted on 10 Jun 2013, 20:57 by charlie6
test pup_event_frontend on wheezy
Hi Barry,
many thanks !
have created both /sbin/pup_event_frontend_d and /usr/local/pup_event/pup_event_frontend_d (created: /usr/local/pup_event folder)
+ rebooted:
- no disk icons displayed
sh-3.00# ./pup_event_frontend_d 

./pup_event_frontend_d: /lib/ version `GLIBC_2.15' not found (required by ./pup_event_frontend_d)

here only have glibc21 (migjt be 2.13).
- rox file manager opens as also mounting of disks throug pmount.
Looks far faster =-) than before ...

Did not find

Posted on 11 Jun 2013, 12:19 by technosaurus
re: pupevent
I started a thread on populating /dev from /sys and we ended up discussing some hotplugging ideas too. Since udev uses the netlink connection, pupevent can be set up as /proc/sys/kernel/hotplug without interfering (and work instantly)

Populating /dev takes only ~0.2s

I've been looking through the old hotplug scripts and mdev / udev etc ... to make a much faster version of the old hotplug scripts ... if they had been written right we wouldn't have needed undeveloped to begin with.

Posted on 11 Jun 2013, 14:41 by K Godt
IF FILEEXISTS("/tmp/wmexitmode.txt")==1 THEN END 8

Can't that be done with a trap/kill statement ?

wmpoweroff, wmreboot, wmexit look horrible with that up to one minute wait for the "@#?!end_d" to not show up in ps output

Posted on 11 Jun 2013, 15:11 by K Godt
not changed much
 if [ "$FD0ICON" = "true" ];then #see /etc/eventmanager

if [ -e /sys/block/fd0 ];then
PROBEDISK="/dev/fd0|floppy|Legacy floppy drive

If me , it would be handled by /sbin/probedisk2
MNTDDEVS="`mount | cut -f 1 -d ' ' | cut -f 3 -d '/' | grep -E '^hd|^sd|^scd|^sr|^mmc|^fd' | tr '\n' ' '`"

ALLDRVS="`ls -1 /sys/block | grep -E '^scd|^sd|^mmc|^sr|^fd' | tr '\n' ' '`"

INFO="MMC/SD: `cat /sys/block/$ONEDRV/device/name`"
INFO='Generic 3 FDD'

tr '\n' ' ' never is needed, and also the double quotes at the beginning and end of the execute string . Not that it is some kind of bloat, but to me it is easier to read in the default geany .sh filetype macro .

Posted on 11 Jun 2013, 16:40 by BarryK
I glanced at your forum thread, and that looks extremely interesting. Yes, the old hotplug technique is intrinsically better than a daemon, if the handler code could have been made fast.

I was almost going to follow what you were doing, as I like it, but then I also want a periodic timed handler for various background housekeeping (currently set at 4 seconds), so I decided to go for the netlink daemon.

K Godt,
No, not one minute, the wait is up to 1 second max. Faster than before, which was up to 2 seconds.

Posted on 11 Jun 2013, 17:19 by BarryK
Re fd0
K Godt,
As I recall, I have done it the way I have done it, because on some PCs /sys/block/fd* exists even when there is no actual floppy disk drive.

That is, the interface is on the motherboard but no actual physical floppy drive. The kernel doesn't detect existence of whether there is an actual floppy drive.

At least, that's how I recall the problem at the time.

Probing for existence of a floppy drive, or for a plugged-in floppy disk, both time-consuming exercises, so I haven't done it. Instead, there is just a variable set by the EventManager.

Posted on 14 Jun 2013, 12:37 by charlie6
new pup_event_frontend_d
Hi Barry,
(here running wheezy-
ooops...! i haven't noticed i had to download the other script from woof - i.e. frontend_startup, etc... - to put in /usr/local/pup_event/.
I also installed bacon2.1.7 and got pup_event_frontend_d compiled to 14K size according to vovchik method (44K otherwise).
Glibc'version is 2.13 here.

Looks working nice since yesterday.
Thanks again

Posted on 14 Jun 2013, 12:50 by charlie6
new pup_event_frontend_d
Hi again,
using new pup_event_frontend_d:

I have currently 2 usb flash plugs inserted.
Unplugging, wait 5 seconds, and plugging just ONE of them again results in:
-unplugging: the corresponding icon disappears;
-plugging again: BOTH icons dispappear and do not come back. The are again displayed after restart X.

Posted on 14 Jun 2013, 17:36 by BarryK
Re disappearing icons
I can't reproduce that. I am wondering if a problem is showing up with a slow CPU -- what CPU do you have?

Anyway, I have put in a sanity check into /usr/local/pup_event/frontend_change, hopefully that will fix it:

Posted on 14 Jun 2013, 23:22 by charlie6
Re disappearing icons
Hi Barry,
here CPU is
Intel(R) Pentium(R) 4 CPU 2.53GHz