IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For renamed network interfaces, the udev socket message header
contained the original devpath, which we have updated in the
environment after the kernel has silently renamed the netif.
Identified by Joachim Plack <jplack@suse.de> while working around
the problem that the device nodes appear and disappear while the
partitiontable is re-read and the application need to waait for an
empty udevd queue.
Apply substitutions before running a program, not while the rule
is parsed. It allows to use environment variables set during rule
processing as command arguments.
We never used any of the libsysfs convenience features. Here we replace
it completely with 300 lines of code, which are much simpler and a bit
faster cause udev(d) does not open any syfs file for a simple event which
does not need any parent device information.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
This allows scripts to do:
while test -d /dev/.udev/queue; do sleep 0.1; done
And don't create a failed symlink if there is another event
for the same devpath in the queue.
All udev state is kept in /$udev_root/.udev/ now. No option to
configure that anymore, it will always be there.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
All pending and running events can be found as symlinks to the actual
device in /dev/.udev/queue/ now. This way we can lookup if specific events
are still in the queue, before doing actions which require events to have
finished.
All failed event processes can be found in /dev/.udev/failed/. This makes
it possible to retry a failed event process at a later time in the boot
process.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
With removing the event reorder queue, we can fix the TIMEOUT events
like firmware loading proper, and never delay any of these events.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Netlink will never get out-of-order and we just depend on it from
now on. Udevsend messages will have no effect if they contain a
sequence number (SEQNUM).
Thanks to Bastian Blank <waldi@debian.org>, for the debugging session
which identified a bug where the timeouts are not working if
inotify was not available. All the timeout handling is removed
now and this issue should be solved.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
It was a workaround for speed up udev "coldplug", where ~800 events
happened a second time during bootup. No need for it with the rules
aleady parsed in the daemon.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Move socket init and rule parsing before forking, so we can start
emitting event immediately after udevd has started.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
The rules files are parsed only once at daemon startup. Every udev
event process will be fork()'d from udevd without exec()'ing the udev
binary. The in-memory rules will be inherited from the daemon itself.
If inotify is available, udevd will reload all rules if any change in
/etc/udev/rules.d/ happens. Otherwise -HUP or "udevcontrol reload_rules"
can be used.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Netlink events get lost when the kernel creates thousends of events
faster than udevd reads it. The default is 128 KB, which can carry
app. 500 events. Set it to 16 MB now.
I have 4000 fibrechannel LUNs connected to my system. There are two
paths to the devices and two ports on the host connected via a switch.
This gives 16000 when probed.
I have had problems getting all of the entries in /dev created.
-- Mark Haverkamp <markh@osdl.org>
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
UDEVD_EVENT_TIMEOUT=0 didn't work directly after udevd startup.
The whole event timeout handling is not needed since we use netlink.
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
Moving events directly to the exec queue instead of the reordering
incoming queue, leaves holes in the sequence, that lead to timeouts for
all other events. Remove that part of the special handling.
(With netlink, events can't get out-of-order and the maximum timeout is 5
seconds and should not cause any trouble with the 10 sec timout for the
firmware class anyway. Events with timeouts are still prioritized for
execution, but don't bypass the incoming queue anymore.)
Many thanks to:
Uberto Barbini <uberto@ubiland.net>
for his endless debugging and sending all the traces, that showed this
failure with his DVB device:
UEVENT[1124474094] add@/module/stv0299
UEVENT[1124474094] add@/module/ves1x93
UEVENT[1124474094] add@/module/ttpci_eeprom
UEVENT[1124474094] add@/module/saa7146
UEVENT[1124474094] add@/module/video_buf
UEVENT[1124474094] add@/module/saa7146_vv
UEVENT[1124474094] add@/module/dvb_core
UEVENT[1124474094] add@/module/dvb_ttpci
UEVENT[1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] add@/class/firmware/0000:00:14.0
UDEV [1124474094] add@/module/dvb_core
UDEV [1124474094] add@/module/saa7146_vv
UDEV [1124474094] add@/module/dvb_ttpci
UDEV [1124474094] add@/module/ves1x93
UDEV [1124474094] add@/module/ttpci_eeprom
UDEV [1124474094] add@/module/saa7146
UDEV [1124474094] add@/module/stv0299
UDEV [1124474094] add@/module/video_buf
UDEV [1124474094] add@/bus/pci/drivers/dvb
UEVENT[1124474094] remove@/class/firmware/0000:00:14.0 <- event with TIMEOUT will leave a hole in the incoming
UDEV [1124474094] add@/class/firmware/0000:00:14.0 sequence, which will cause a wait for the alarm()
UEVENT[1124474094] add@/class/i2c-adapter/i2c-1 that flushes the queue
UEVENT[1124474094] add@/class/i2c-dev/i2c-1
UDEV [1124474094] remove@/class/firmware/0000:00:14.0 <- event also has TIMEOUT and is executed immediately
UEVENT[1124474095] add@/class/dvb/dvb0.demux0
UEVENT[1124474095] add@/class/dvb/dvb0.dvr0
UEVENT[1124474095] add@/class/dvb/dvb0.video0
UEVENT[1124474095] add@/class/dvb/dvb0.audio0
UEVENT[1124474095] add@/class/dvb/dvb0.ca0
UEVENT[1124474095] add@/class/dvb/dvb0.osd0
UEVENT[1124474095] add@/class/dvb/dvb0.net0
UEVENT[1124474095] add@/class/video4linux/video1
UEVENT[1124474095] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/i2c-adapter/i2c-1 <- all others have 5 seconds delay cause of the missing event
UDEV [1124474099] add@/class/dvb/dvb0.ca0 missing events
UDEV [1124474099] add@/class/dvb/dvb0.osd0
UDEV [1124474099] add@/class/video4linux/video1
UDEV [1124474099] add@/class/dvb/dvb0.frontend0
UDEV [1124474099] add@/class/dvb/dvb0.video0
UDEV [1124474099] add@/class/dvb/dvb0.audio0
UDEV [1124474099] add@/class/i2c-dev/i2c-1
UDEV [1124474099] add@/class/dvb/dv
My test program that simulates a similar sequence, runs without any delay
now. (With one of the next versions we will make netlink mandatory, then
we can remove the whole input queue crap with the reordering anyway.)
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
If the kernel forks us as an usermodhelper, we don't have any of
the standard fd's and the first open() will start with fd=0.
This is inherited to all forked childs and confuses later forked
helpers where we want to read from a pipe connected to the helpers
stdout/stderr.
# ls -l /proc/$(pidof udevd)/fd
total 6
dr-x------ 2 root root 0 2005-08-18 12:44 .
dr-xr-xr-x 4 root root 0 2005-08-18 12:44 ..
lrwx------ 1 root root 64 2005-08-18 12:44 0 -> /dev/null
lrwx------ 1 root root 64 2005-08-18 12:44 1 -> socket:[1274617]
lr-x------ 1 root root 64 2005-08-18 12:44 2 -> pipe:[1274618]
l-wx------ 1 root root 64 2005-08-18 12:44 3 -> pipe:[1274618]
lrwx------ 1 root root 64 2005-08-18 12:44 4 -> socket:[1274619]
lrwx------ 1 root root 64 2005-08-18 12:44 5 -> socket:[1274620]
Ouch! This will obviously not redirect sterr, it will kill the pipe
we established between the parent and the child:
devnull = open("/dev/null", O_RDWR);
dup2(devnull, STDERR_FILENO);
Signed-off-by: Kay Sievers <kay.sievers@suse.de>
