After updating to udev-132 a custom rule in /etc/udev/rules.d won't work anymore. If the rule matches, three processes of "udev --daemon" are started (each with my custom script as child process) but nothing happens = the script doesn't start. The symlink in /dev is created. Everything worked fine before updating to udev-132... SUBSYSTEMS=="scsi", ATTRS{vendor}=="ST916082", ACTION=="add", NAME="%k", SYMLINK+="drive-n-go%n", RUN+="/etc/crypto/scripts/mnt_drive-n-go", ENV{ACTION}=”add” Reproducible: Always Steps to Reproduce: Portage 2.2_rc14 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r0, 2.6.27.6 x86_64) ================================================================= System uname: Linux-2.6.27.6-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4000+-with-glibc2.2.5 Timestamp of tree: Sat, 15 Nov 2008 13:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r6, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 9999 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" LANG="de_DE.UTF-8" LC_ALL="de_DE.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/java-overlay /usr/portage/local/layman/sunrise /usr/portage/local/layman/alon-barlev /usr/portage/local/layman/jokey /usr/portage/local/layman/desktop-effects /usr/portage/local/layman/gimpel /usr/portage/local/layman/xake-toolchain /usr/portage/local/layman/synce /usr/portage/local/layman/openrc /usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 acl acpi alsa amd64 avahi berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus dri dvd dvdr eds encode esd exif ffmpeg fortran gdbm glitz gnome gphoto2 gpm gstreamer gtk hal iconv imap ipv6 isdnlog jpeg libnotify lm_sensors midi mmx mmxext mp3 mpeg mudflap multilib ncurses nls nptl nptlonly nsplugin ogg openmp pam pcre pdf perl png pppd python quicktime readline reflection samba session spell spl sse sse2 ssl svg sysfs tcpd threads tiff truetype truetype-fonts type1-fonts unicode vorbis xorg xulrunner xvid zlib" ALSA_CARDS="snd-hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Output of pstree: udevd,2509 --daemon ├─udevd,13857 --daemon │ └─mnt_drive-n-go,13964 /etc/crypto/scripts/mnt_drive-n-go │ └─sleep,14915 1 ├─udevd,14011 --daemon │ └─mnt_drive-n-go,14016 /etc/crypto/scripts/mnt_drive-n-go │ └─sleep,14918 1 ├─udevd,14014 --daemon │ └─mnt_drive-n-go,14015 /etc/crypto/scripts/mnt_drive-n-go │ └─sleep,14917 1 ├─udevd,14020 --daemon │ └─mnt_drive-n-go,14021 /etc/crypto/scripts/mnt_drive-n-go │ └─sleep,14919 1 └─udevd,14806 --daemon └─mnt_drive-n-go,14807 /etc/crypto/scripts/mnt_drive-n-go └─sleep,14916 1
Script that should be triggered by udev rule: #!/bin/bash # check action if [ "$ACTION" = "add" ]; then /bin/sleep 2 # create cryptodevice /sbin/cryptsetup --key-file /etc/crypto/drive-n-go.key luksOpen dev/drive-n-go1 drivengo & while [ ! -e /dev/mapper/drivengo ]; do sleep 1; done # and mount it /bin/mount /mnt/drivengo # /bin/mount /mnt/backup fi if [ "$ACTION" = "remove" ]; then /bin/umount /mnt/backup /bin/umount /mnt/drivengo # close cryptodevice /sbin/cryptsetup luksClose drivengo fi exit 0
Likely caused by using the CONFIG_SYSFS_DEPRECATED kernel config option. The next version of udev is expected to work with the deprecated sysfs layout again. Btw, ENV{ACTION}=”add” looks really wrong, you can not overwrite primary kernel supplied values. You must always also match on "change" events if you match on "add", otherwise any "change" event will remove the symlink. NAME="%k" does nothing, it's the default.
(In reply to comment #3) > Likely caused by using the CONFIG_SYSFS_DEPRECATED kernel config option. The > next version of udev is expected to work with the deprecated sysfs layout > again. So I just change this in kernel config and everything should work again? > Btw, ENV{ACTION}=”add” looks really wrong, you can not overwrite primary > kernel supplied values. Oh, I thought that this only sets $ACTION = "add" as an enviroment variable. > You must always also match on "change" events if you match on "add", otherwise > any "change" event will remove the symlink. Thanks for your hints!
(In reply to comment #4) > (In reply to comment #3) > > Likely caused by using the CONFIG_SYSFS_DEPRECATED kernel config option. The > > next version of udev is expected to work with the deprecated sysfs layout > > again. > > So I just change this in kernel config and everything should work again? I guess so. We fixed a bug where ATTRS did not work correctly, and it failed to find all parent devices. This happened only with the deprecated sysfs layout. It's expected to work again with the just released udev 133. > > Btw, ENV{ACTION}=”add” looks really wrong, you can not overwrite primary > > kernel supplied values. > > Oh, I thought that this only sets $ACTION = "add" as an enviroment variable. ACTION, SUBSYSTEM, DEVPATH, DRIVER, and some others are kernel-supplied values, and not supposed to be touched by ENV{} keys. Run: udevadm monitor --env and plug-in a device, you will see the udev generated keys, and the kernel suppplied keys, printed in two sections for every event.
Maybe you want to check udev-133 that I commited yesterday. It still is masked until it is tested. To check it now, do: echo "=sys-fs/udev-133" >> /etc/portage/package.unmask emerge udev
I just changed the kernel option (CONFIG_SYSFS_DEPRECATED=n) and updated to udev-133. At boot time I get this error message: Nov 22 11:57:08 tux udevd[1209]: PHYSDEV* values are deprecated and not available on recent kernels, please fix it in /lib64/udev/rules.d/30-kernel-compat.rules:6 Nov 22 11:57:08 tux udevd[1209]: PHYSDEV* values are deprecated and not available on recent kernels, please fix it in /lib64/udev/rules.d/30-kernel-compat.rules:12 When I plug in the usb hdd the rule matches and some processes are started: 5837 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6029 ? S< 0:00 /sbin/udevd --daemon 6030 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6031 ? S< 0:00 /sbin/udevd --daemon 6033 ? S< 0:00 /sbin/udevd --daemon 6034 ? S< 0:00 /sbin/udevd --daemon 6035 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6039 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6050 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6537 ? S< 0:00 sleep 1 6538 ? S< 0:00 sleep 1 6539 ? S< 0:00 sleep 1 6540 ? S< 0:00 sleep 1 6541 ? S< 0:00 sleep 1 The rule is SUBSYSTEMS=="scsi", ATTRS{vendor}=="ST916082", SYMLINK="drive-n-go%n", ACTION=="add", RUN+="/etc/crypto/scripts/mnt_drive-n-go" After some time more processes are started: 5837 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6030 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6035 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6039 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6050 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 6987 ? S< 0:00 /sbin/udevd --daemon 6991 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go 7006 ? S<L 0:01 /sbin/cryptsetup --key-file /etc/crypto/drive-n-go.key luksOpen /dev/drive-n-go 7020 ? S< 0:00 [kdmflush] 7021 ? S< 0:00 [kcryptd_io] 7022 ? S< 0:00 [kcryptd] 7023 ? S< 0:00 /sbin/udevadm settle 7279 ? S< 0:00 sleep 1 7280 ? S< 0:00 sleep 1 7281 ? S< 0:00 sleep 1 7282 ? S< 0:00 sleep 1 7283 ? S< 0:00 sleep 1 7284 pts/0 R+ 0:00 ps ax 7285 ? S< 0:00 sleep 1 Some minutes later the drive is mounted and everything is fine. But the time delay and the race(?) of all these processes is really enoying.
(In reply to comment #7) > At boot time I get this error message: > > Nov 22 11:57:08 tux udevd[1209]: PHYSDEV* values are deprecated and not > available on recent kernels, please fix it in > /lib64/udev/rules.d/30-kernel-compat.rules:6 These compat rules should all be pre 2.6.18 material, a kernel version which we do not support anymore for other reasons. I'm pretty sure, these rules can be removed for kernels after 2.6.17. The warning does not do any harm though, it's meant to tell people that they have rules which can never match, because these values have been removed from the kernel since a while. > When I plug in the usb hdd the rule matches and some processes are started: > > 5837 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go > 6029 ? S< 0:00 /sbin/udevd --daemon > 6030 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go > 6031 ? S< 0:00 /sbin/udevd --daemon > 6033 ? S< 0:00 /sbin/udevd --daemon > 6034 ? S< 0:00 /sbin/udevd --daemon > 6035 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go > 6039 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go > 6050 ? S< 0:00 /bin/bash /etc/crypto/scripts/mnt_drive-n-go > The rule is > SUBSYSTEMS=="scsi", ATTRS{vendor}=="ST916082", SYMLINK="drive-n-go%n", > ACTION=="add", RUN+="/etc/crypto/scripts/mnt_drive-n-go" > Some minutes later the drive is mounted and everything is fine. But the time > delay and the race(?) of all these processes is really enoying. Does the device have partitions? This script will start for every partition at the disk. If the device has partitions, how many of them are encryped? Udev probes the device anyway, and finds out that it is a LUKS device. If you make sure your rule comes after the 60-persistent-storage*, you can match on ENV{ID_FS_TYPE}=="crypto_LUKS" and start the script only for encrypted partitons, which will be much more efficient. Also SUBSYSTEM=="block" is needed, to trigger the script only for block devices, currently you start it for every possible device which is a child of the scsi device, which might not be limited to block devices.
(In reply to comment #8) Thanks again for your hints :-) I changed the rule a little bit and everything works fine... except this enoying delay until the drive is mounted. I think it is "/sbin/udevadm settle" called by cryptsetup and waiting for something until timeout?
(In reply to comment #9) > Thanks again for your hints :-) I changed the rule a little bit and everything > works fine... Great! Thanks for the tests! > except this enoying delay until the drive is mounted. I think it > is "/sbin/udevadm settle" called by cryptsetup and waiting for something until > timeout? Ouch! No tool which may possibly be called from a udev rule can ever use "settle". It will always deadlock, because the event that calls the tool, is a running event itself, and will wait for itself to "settle". That must be fixed in cryptsetup. Seems it's a known issue: http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2804 http://bugs.gentoo.org/242778
(In reply to comment #10) > Ouch! No tool which may possibly be called from a udev rule can ever use > "settle". It will always deadlock, because the event that calls the tool, is a > running event itself, and will wait for itself to "settle". That must be fixed > in cryptsetup. Ah, fine, that seems fixed upstream. I find this in the cryptsetup sources: "Use remapping to error target instead of calling udevsettle for temporary crypt device." http://code.google.com/p/cryptsetup/source/detail?r=32&path=/trunk/lib/libdevmapper.c#
(In reply to comment #11) > Ah, fine, that seems fixed upstream. It has been fixed in trunk, so the normal portage user has to wait until the next release of cryptsetup?
(In reply to comment #12) > (In reply to comment #11) > > Ah, fine, that seems fixed upstream. > > It has been fixed in trunk, so the normal portage user has to wait until the > next release of cryptsetup? I can't tell how such package updates are managed in Gentoo, I just check the bugs here when I find the time, and especially when we did major changes, and track possible new bugs we introduced. Gentoo is pretty unique with all the different options and combinations people use on their systems. The big distros are doing almost all the same these days, and never encounter some problems, because they use only a very limited subset of the possible variations in the system environment. Same is true for build/compilation problems we introduce with a new version. They are almost all found/reported by Gentoo users. :) So, thanks for your help again! For the cryptsetup problem, care to check with the Gentoo package maintainer of cryptsetup? I guess the patch should be included in the current cryptsetup, if there is no new upstream release expected anytime soon.
(In reply to comment #13) > For the cryptsetup problem, care to check with the Gentoo package maintainer of > cryptsetup? I guess the patch should be included in the current cryptsetup, if > there is no new upstream release expected anytime soon. Just for the records: The patch for cryptsetup from #242778 works fine with the cryptsetup-1.0.6-r2. The patch comes from cryptsetup-svn and has to replace the existing cryptsetup-1.0.6-udevsettle.patch I think this bug could be set to resolved.
