There's still a slight race condition when using udevadm settle, if the
udev daemon has a pending inotify event but hasn't yet generated the
"change" uevent for it, the kernel and udev sequence numbers will match
and settle will exit.
Now udevadm settle will send a control message to udevd, which will
respond by sending SIGUSR1 back to the waiting udevadm settle once it
has completed the main loop iteration in which it received the control
message.
If there were no pending inotify events, this will simply wake up the
udev daemon and allow settle to continue. If there are pending inotify
events, they are handled first in the main loop so when settle is
continued they will have been turned into uevents and the kernel
sequence number will have been incremented.
Since the inotify event is pending for udevd when the close() system
call returns (it's queued as part of the kernel handling for that system
call), and since the kernel sequence number is incremented by writing to
the uevent file (as udevd does), this solves the race.
When the settle continues, if there were pending inotify events that
udevd had not read, they are now pending uevents which settle can wait
for.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Use calloc to request cleared memory instead.
Kernel and libc conspire to make this more efficient.
Also, replace one malloc() + strcpy() with strdup().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
strerror() is not threadsafe. It uses a buffer to build messages of the form
"Unknown error 387689".
syslog() provides a %m format which is equivalent to strerror(errno).
As a GNU extension, this is also accepted by printf and friends.
At least in the current implementation, it is correctly threadsafe.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
This was needed in the old days, where all the hotplug scripts did
nothing better than sleep for seconds to work around timing issues.
It made sure, that w continued to fork processes, while the machine
was doing nothing than sleeping, but the maximim number of childs
was already reached. This is no longer needed today, we do not run
many of these scripts anymore.
