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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A common use (e.g. in Ubuntu) for udevadm monitor is to log the events
received by udev during boot; events can be lost of the buffer size isn't
increased as udevd does.
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
We do no longer delete the primary device node while handling "remove"
events if the same kernel device is already re-created in the meantime.
This prevents the asynchronously running udev from removing and re-creating
primary device nodes for active devices.
It handles only RUN but not IMPORT and PROGRAM. There is no sane way
to suppress program execution. Most important programs run with IMPORT
these days. Also events can no longer suppressed with the libudev
netlink messages, so UDEV_RUN does nothing useful and is just
inconsistent.
There is no way to ignore an event these days. Libudev events can
not be suppressed. It only prevents RUN keys from being executed,
which results in an inconsistent behavior in current setups.
This should also address:
On Tue, Nov 3, 2009 at 16:21, Marco d'Itri <md@linux.it> wrote:
> udev_rules_new() in udev/udev-rules.c unconditionally creates the
> directory.
> This is a problem because the function is called also by e.g. udevadm
> test, and creating /dev/.udev/ when it does not exist is an unacceptable
> side effect which will break everything else that checks for its
> existence to know if udev is running.
link_find_prioritized(): Properly close directory handles to fix a major fd
leak which caused hotplugging to fail entirely in many cases due to having too
many open files.
https://launchpad.net/bugs/463347
On Thu, Oct 29, 2009 at 19:15, Christian P. Schmidt <schmidt@digadd.de> wrote:
> After the getty replaces itself with login the pam module pam_mount
> calls mount. This in turn determines that the partition to be mounted is
> LUKS encrypted, and calls cryptsetup. Cryptsetup receives the password,
> unlocks the partition, and calls udevadm settle in order to avoid some
> problems in interaction with LVM.
>
> udevadm settle never returns.
>
> The problem here is that SIGUSR1 and SIGALRM are both blocked in oldmask
> already, and never reach udevadm. No care is ever taken to ensure those
> signals are not blocked.
Its use breaks too many things which expect to be run from independent
later rules, and is an idication that something needs to be fixed
properly instead.
On Wed, Oct 7, 2009 at 21:46, Alan Jenkins <sourcejedi.lkml@googlemail.com> wrote:
> Udev would have avoided the race prior to
>
> 82c785e "udevd: remove check for dev_t, DEVPATH_OLD takes care of that"
>
> (the "check" removed here used to serialize events based on the device
> major:minor number).
On Wed, Oct 7, 2009 at 22:31, Michael Guntsche <mike@it-loops.com> wrote:
> add /module/8250_pnp (module)
> remove /devices/platform/serial8250/tty/ttyS0 (tty)
> add /devices/pnp0/00:05/tty/ttyS0 (tty)
On Wed, Sep 23, 2009 at 23:11, Matthias Schwarzott <zzam@gentoo.org> wrote:
> It is about ioctl failures on amd64:
> http://bugs.gentoo.org/show_bug.cgi?id=286041
>
> A bad parameter type to an ioctl() call causes udev-146 to generate "error
> getting buffer for inotify" messages in syslog. The offending code is
> roughly:
>
> ssize_t nbytes, pos;
> // ...
> ioctl(fd, FIONREAD, &nbytes);
>
> where ssize_t is 64 bits on amd64, but the kernel code for FIONREAD (at least
> through gentoo-sources-2.6.31) uses type int:
>
> p = (void __user *) arg;
> switch (cmd) {
> case FIONREAD:
> // ...
> ret = put_user(send_len, (int __user *) p);
>
> so the upper 32 bits of "nbytes" are left uninitialized, and the subsequent
> malloc(nbytes) fails unless those 32 bits happen to be zero (or the system has
> a LOT of memory).
On 8/29/09, Florian Zumbiehl <florz@florz.de> wrote:
> Could it happen that > util_create_path() and util_delete_path()
> do run in parallel for > the same directory? After all, util_create_path()
> does handle > the case where creation of the directory happens in parallel
> to it running, so it doesn't seem all that unlikely to me ...
With well defined and kernel-supplied node names, we no longer need
to support a possible stack of conflicting symlinks and node names.
Only symlinks with identical names can be claimed by multiple devices.
This shrinks the former /dev/.udev/names/ significantly.
Also the /dev/{block,char}/MAJ:MIN" links are excluded from the name
stack - they are unique and can not conflict.
External programs triggered by events (via RUN=) will inherit udev's
signal mask, which is set to block all but SIGALRM. For most utilities,
this is OK, but if we start daemons from RUN=, we run into trouble
(especially as SIGCHLD is blocked).
This change saves the original sigmask when udev starts, and restores it
just before we exec() the external command.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
That was a mistake. The variable is needed to be set before
we parse the file. Thanks a lot to Alan Jenkins for spotting
this.
This reverts commit 710fdac1e4.
POSIX.1-2001 declares usleep() function obsolete and POSIX.1-2008
removes it.
[Kay Sievers]
- include time.h
- use const for timespec
- scsi_id: drop rand() in retry loop
- modem-probe: rename msuspend() to msleep()
On Sun, Aug 30, 2009 at 04:36, Marco d'Itri<md@linux.it> wrote:
> inotify_add_watch may fail in udev_watch_begin, and then a link with
> name -1 is created.
> I do not know why, but it happened once on my system:
>
> lrwxrwxrwx 1 root root 27 Aug 4 11:27 -1 -> /devices/virtual/block/ram8
With very deeply nested devices, We can not use a single file
name to carry an entire DEVPATH. Use <subsystem>:<sysname> as
the database filename, which should also simplify the handling
of devices moving around, as these values will not change but
still be unique.
For the name stack we use the <maj>:<min> now as the filename.
> On Tue, Aug 18, 2009 at 09:59:56AM -0400, Ric Wheeler wrote:
> The first is that udev grumbles during boot about "file name too long"
> like the following:
>
> Aug 17 06:49:58 megadeth udevd-event[20447]: unable to create db file
> '/dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:04.0\x2f0000:17:00.0\x2f0000:18:0a.0\x2f0000:1f:00.0\x2fhost11\x2fport-11:0\x2fexpander-11:0\x2fport-11:0:0\x2fexpander-11:1\x2fport-11:1:0\x2fexpander-11:2\x2fport-11:2:17\x2fexpander-11:3\x2fport-11:3:1\x2fend_device-11:3:1\x2fbsg\x2fend_device-11:3:1':
> File name too long
