Udev fixed, inotify 0.5

There were some problems with udev in Puppy, now fixed I think.

Udev rule problem
One problem was this udev rule:

ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="disk", RUN+="/bin/sh -c 'echo ACTION=$ACTION SUBSYSTEM=$SUBSYSTEM DEVTYPE=$DEVTYPE DEVPATH=$DEVPATH > /tmp/pup_event_backend_s'"

This rule is how udevd notifies my frontend daemon, pup_event_frontend_d, when a drive is inserted. However, I was getting strange behaviour, and I eventually discovered that udevd was also writing to /tmp/pup_event_backend_s when:
ACTION=="add", SUBSYSTEM=="block", DEVTYPE=="partition"
which caused two (or more) messages when my frontend script was only expecting one.

It seems that udevd is trying to be clever and has ignored the explicit instructions in the rule (unless I have misunderstood the rules syntax, which wouldn't surprise me). Anyway, I put in a fix.

inotail utility
The other problem I fixed was more of a potential bug. I was using 'inotifywait' to wait until /tmp/pup_event_backend_s is modified, and my script read the file after detecting a modification. However, there is a potential failure if udevd too-rapidly writes again to the file.
I don't have this potential problem with my own pup_event_backend_d daemon (alternative to udevd).

Anyway, I fixed the problem by changing from 'inotifywait' to 'inotail'. The latter is a tail utility that is especially useful to run in daemon mode (inotail -f <file>) as it uses the inotify mechanism, so uses very little resources while waiting for a file to be modified.

---

Comments

hits counter


Re: inotifywait versus inotail
Username: BarryK
"There is another reason why inotail is preferable. [i]inotifywait -e modify <filename>[/i] returns as soon as it detects a file modification, whereas I would prefer the return after a complete line is written. [i]inotail -f <filename>[/i] will return the complete appended line.

Tags: puppy