You are not logged in.
Pages: 1
I'm writing two udev-rules and having some difficulties deciding what hard drive + usb drive properties/attributes that are best to match against in my .rules file. My 10-local.rule file currently contains this for testing:
ACTION=="add", ATTRS{idVendor}=="0951", ATTRS{idProduct}=="1642", RUN+="/home/herman/add.bash"
ACTION=="remove", ENV{ID_FS_UUID}=="1420-E86E", ENV{ID_MODEL}=="DT_101_G2", RUN+="/home/herman/rm.bash"
The add/rm scripts only logs to a file whether the usb drive is plugged/unplugged. Udev calls the rm.bash script as it should; only once per removal, but when plugging in the usb drive add.bash gets called multiple times (10 or more). This means that first the rule is matched against some properties multiple times. ATTRS{idVendor} and ATTRS{idProduct} have both unique values, so how come? I'm using the following commands to check what properties to add:
udevadm -a -n /dev/sdb
What can I do in order to make sure the "add" rule is only executed once per plugging?
Last edited by hesse (2012-06-10 10:53:17)
Offline
Ok, found out the solution to my previous problem. I had to add KERNEL=="sd?1" not just KERNEL=="sd?". My 10-local.rules file now looks like this:
# log file
ENV{log_file}="/var/log/udev.log"
# mount options
ENV{opt}="gid=100,umask=002,noauto,user,rw,exec"
# pendrive
ACTION=="add", KERNEL=="sd?1", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}=="Kingston", ATTRS{model}=="DT 101 G2", RUN+="/bin/sh -c 'echo $($env{log_opt}): [%k] pendrive plugged >> $env{log_file}'", RUN+="/bin/mount -t vfat -o $env{opt} /dev/%k /mnt/usb"
ACTION=="remove", ENV{ID_FS_UUID}=="1420-E86E", ENV{ID_MODEL}=="DT_101_G2", RUN+="/bin/sh -c 'echo $($env{log_opt}): [%k] pendrive unplugged >> $env{log_file}'", RUN+="/bin/umount -l /dev/%k"
# lacie
ACTION=="add", KERNEL=="sd?1", SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{vendor}=="ST964032", ATTRS{model}=="2AS", RUN+="/bin/sh -c 'echo $($env{log_opt}): [%k] lacie plugged >> $env{log_file}'", RUN+="/bin/mount -t ntfs -o $env{opt} /dev/%k /mnt/lacie"
ACTION=="remove", ENV{ID_FS_UUID}=="1C8766D25CF21906", ENV{ID_FS_LABEL}=="lacie", ENV{ID_SERIAL}=="ST9640322AS_5WX0WJ8V", RUN+="/bin/sh -c 'echo $($env{log_opt}): [%k] lacie unplugged >> $env{log_file}'", RUN+="/bin/umount -l /dev/%k"
This works great with automounting both my pendrive and my lacie hard drive. However, the "remove" part doesn't work as expected: I tested adding a file to my pendrive and then unplugging it and re-plugging it. The file was never written to it. Does the umount-part happen after the drive is removed? Is the only solution to manually umount it before unplugging? What's the point of having this "remove" part then? Thanks.
Last edited by hesse (2012-06-09 22:03:46)
Offline
why not just use udisks with a helper like devmon ?
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
I think part of the problem is that you're using ATTRS rather than ATTR. The different is subtle -- ATTR will only match against the device that triggered the event, but ATTRS will walk up the device chain and match against the first parent device it finds which matches.
As an aside, using udev rules to mount devices is totally bogus. Upstream considers it a complete abuse of rules. To wit, your remove rule doesn't work because by the time the udev event showing the removal is fired, the device is unplugged and the filesystem is gone. What exactly do you think you're unmounting?
Offline
As an aside, using udev rules to mount devices is totally bogus. Upstream considers it a complete abuse of rules.
I see. Why is it bogus? The rules works fine so far. Is it preferred to use some kind of wrapper like udisks instead? I can see that it may be more convenient, but if this setup works.. I'm happy.
About the removal rules - they were taken straight from the wiki's examples to begin with so I thought it was necessary. They are supposed to " # Clean up after removal". As observed in my last post the filesystem was never written to, so i figured I had to manually unmount it first.
Offline
Offline
udev rules are meant to perform simple operations like setting mode, ownership, creating symlinks, and adding attributes to device nodes. They were never intended to do anything complex like mount filesystems.
This.
Thank you, falconindy, for legitimizing by word what I have always felt- disdain for mounting by udev rules. It has always seemed awkward and inappropriate to me.
Offline
IMHO, "About udev rules" is an unfortunate subject, even worse for searching and archive. Better change it to "About udev rules for HDD and USB drive" or similarly meaningful.
Mateusz Loskot | github | archlinux-config
Arch (x86-64) | ThinkPad T400 | Intel P8600| Intel i915
Arch (x86-64) | ThinkPad W700 | Intel T9600 | NVIDIA Quadro FX 2700M
Offline
I agree with preceding posts about not using udev rules to launch complex tasks from there; I've even seen launching a graphical program from udev rules, though it is not even sure that the Xorg server is running!
The 'devmon' udisks wrapper bash script is very complete and gives many features. Personally, I propose a simpler udisks wrapper GUI version with less features which is called 'udisksvm'; it is for those who like icons and using the mouse to accomplish easy tasks. There is also 'udiskie' the first one developed in this category. The wiki mentions also a 'udisksevt' haskell program, but it doesn't seem to be maintained anymore and it requires to install haskell to compile it.
Offline
$ less /etc/udev.debian/rules.d/z60_hdparm.rules
ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]", RUN+="/etc/init.d/hdparm hotplug"
I've been trying to figure out how to configure udisks but the manual pages mention variables being set in the udev database and I'm not sure how that relates to controlling the mounting of removable drives without using udev rules. Is this where the use of a wrapper script comes in? If so, is that consistent with using KDE? The wiki suggests that udisks is sufficient for automounting on KDE/Gnome but I want to do something a little more complicated and control mounting of specific devices via cron jobs. So I don't want just "automount everything" (which is currently disabled). And I need things to be mounted at certain mount points etc. <path to root of external drive>/boot/efi in order for backups to run smoothly.
(I have udisks installed and udisks-daemon is running:
2078 ? Sl 0:20 /usr/lib/udisks/udisks-daemon
2085 ? S 0:00 udisks-daemon: not polling any devices
Do I need the wrapper to control it from a script? KDE never seems to be able to (un)mount removable hard drives anyway - it offers to but always fails. (Flash drives etc. work fine.)
Last edited by cfr (2012-06-12 01:04:43)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
but I want to ... control mounting of specific devices via cron jobs ... And I need things to be mounted at certain mount points etc ... in order for backups to run smoothly ...
For that I don't think either udev rules or a udisks wrapper script will do it.
You need to write a specific script to be executed as a cron job, which does the mounting when and where you want it.
Either use 'mount' as root or 'pmount' as user.
I think you could open a new thread for that particular problem, if you need help writing that script.
Offline
As a result of this discussion some wiki-user has removed the section that gives direction on how to make working udev rules on USB hot-plugging.
As those tips are removed, we deprived those who wants their own setup of valuable information.
This discussion just reveals lack of the documentation and examples on UDev rules. I think, "safeguarding" users from udev rules just hides the KISS way and exposes wrappers and bloatware of PolKit and UDisks. We just cut the choices and new users never know about abilities of udev and possibilities this subsystem may reveal for them.
The article about UDev: https://wiki.archlinux.org/index.php/Udev
Last edited by Pavel Kolesnikov (2012-07-27 19:18:01)
Offline
cfr wrote:but I want to ... control mounting of specific devices via cron jobs ... And I need things to be mounted at certain mount points etc ... in order for backups to run smoothly ...
For that I don't think either udev rules or a udisks wrapper script will do it.
You need to write a specific script to be executed as a cron job, which does the mounting when and where you want it.
Either use 'mount' as root or 'pmount' as user.
I think you could open a new thread for that particular problem, if you need help writing that script.
Thanks and sorry I forgot to follow this up. I ended up doing as you suggested. (Actually, I incorporated it into one of the scripts involved in the cron job already. Since it is specific to that job I saw no reason to create an additional script.)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
About udisks and the udev rules
As a result of this discussion some wiki-user has removed the section that gives direction on how to make working udev rules on USB hot-plugging.
As those tips are removed, we deprived those who wants their own setup of valuable information.This discussion just reveals lack of the documentation and examples on UDev rules. I think, "safeguarding" users from udev rules just hides the KISS way and exposes wrappers and bloatware of PolKit and UDisks. We just cut the choices and new users never know about abilities of udev and possibilities this subsystem may reveal for them.
The article about UDev: https://wiki.archlinux.org/index.php/Udev
I think using udev rules to hot-plugging is very well.
frist,if i use "udisk wrappers" such as devmon or ldm,i need the program running in background all the time,so it can checkout the usb and mount it.the udev rules don't need the program running all the time
second, the shell script(or commad) in udev rules to automount is not very easy to write and man cause problem,but udev rules can work with 'udisk wrappers' well.
such as devmon ,pmount,i.e. the result udev rules is very simple and easy to write and understand.
i think this is a simple way to do hot-plugging thing.
sorry for my poor english.
Offline
ENV{ID_FS_UUID}==
Such matching can only be done after the ENV vars have been set up, which is done in 60-persistent-storage.rules
So use a rule filename > 60
Offline
Pages: 1