udev rule not working












1















I have created a udev rules which is supposed to mount a USB device, backup some datas et cleanup everything. I am actually working on a Debian server.



There is the information about my usb device that I have with lsusb




Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive




(Actually the lsusb returns more Bus / Device, but I have to write them by hand since I am not posting from my Debian machine :))



Then I have written my udev rule called :



10-usb_back.rules


into:



/etc/udev/rules.d/


(I used 95 because the backup script takes some seconds and I want to run it as late as I can for avoiding to delay other stuff)



And finally the rule itself:



ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/mount_usb"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/backup_database"


I have tried this too:



ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054c", ATTR{idProduct}=="0234", RUN+="bash /usr/local/bin/mount_usb"


Unsuccessfully :(



Then I restart udev



sudo /etc/init.d/udev restart


And when I plug my USB device I got this weird message:




[1348.295280] sd 6:0:0:0: [sdc] Assuming drive cache: write through




twice



But nothing happened. No USB device mounted, no data backed up.



I looked with tail -f /var/log/message


And the USB drive looks like detected:



usb 1-3: Product Storage Media 
usb 1-3 Manufacturer Sony`
...


Something must be wrong somewhere but I don't know what, neither where :(



Edit: Since I've been a little bit lazy because I can't rewrite everything from my server, please ask for further information if needed, such as the script or more logs messages :)










share|improve this question

























  • You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

    – Kotte
    May 16 '13 at 8:54











  • I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

    – Edelweiss
    May 16 '13 at 9:09











  • Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

    – Kotte
    May 16 '13 at 9:31











  • I had the same problem a while ago. Mabye that solution will work for you too.

    – user13742
    May 16 '13 at 12:51











  • @don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

    – Edelweiss
    May 17 '13 at 6:50


















1















I have created a udev rules which is supposed to mount a USB device, backup some datas et cleanup everything. I am actually working on a Debian server.



There is the information about my usb device that I have with lsusb




Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive




(Actually the lsusb returns more Bus / Device, but I have to write them by hand since I am not posting from my Debian machine :))



Then I have written my udev rule called :



10-usb_back.rules


into:



/etc/udev/rules.d/


(I used 95 because the backup script takes some seconds and I want to run it as late as I can for avoiding to delay other stuff)



And finally the rule itself:



ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/mount_usb"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/backup_database"


I have tried this too:



ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054c", ATTR{idProduct}=="0234", RUN+="bash /usr/local/bin/mount_usb"


Unsuccessfully :(



Then I restart udev



sudo /etc/init.d/udev restart


And when I plug my USB device I got this weird message:




[1348.295280] sd 6:0:0:0: [sdc] Assuming drive cache: write through




twice



But nothing happened. No USB device mounted, no data backed up.



I looked with tail -f /var/log/message


And the USB drive looks like detected:



usb 1-3: Product Storage Media 
usb 1-3 Manufacturer Sony`
...


Something must be wrong somewhere but I don't know what, neither where :(



Edit: Since I've been a little bit lazy because I can't rewrite everything from my server, please ask for further information if needed, such as the script or more logs messages :)










share|improve this question

























  • You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

    – Kotte
    May 16 '13 at 8:54











  • I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

    – Edelweiss
    May 16 '13 at 9:09











  • Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

    – Kotte
    May 16 '13 at 9:31











  • I had the same problem a while ago. Mabye that solution will work for you too.

    – user13742
    May 16 '13 at 12:51











  • @don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

    – Edelweiss
    May 17 '13 at 6:50
















1












1








1


1






I have created a udev rules which is supposed to mount a USB device, backup some datas et cleanup everything. I am actually working on a Debian server.



There is the information about my usb device that I have with lsusb




Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive




(Actually the lsusb returns more Bus / Device, but I have to write them by hand since I am not posting from my Debian machine :))



Then I have written my udev rule called :



10-usb_back.rules


into:



/etc/udev/rules.d/


(I used 95 because the backup script takes some seconds and I want to run it as late as I can for avoiding to delay other stuff)



And finally the rule itself:



ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/mount_usb"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/backup_database"


I have tried this too:



ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054c", ATTR{idProduct}=="0234", RUN+="bash /usr/local/bin/mount_usb"


Unsuccessfully :(



Then I restart udev



sudo /etc/init.d/udev restart


And when I plug my USB device I got this weird message:




[1348.295280] sd 6:0:0:0: [sdc] Assuming drive cache: write through




twice



But nothing happened. No USB device mounted, no data backed up.



I looked with tail -f /var/log/message


And the USB drive looks like detected:



usb 1-3: Product Storage Media 
usb 1-3 Manufacturer Sony`
...


Something must be wrong somewhere but I don't know what, neither where :(



Edit: Since I've been a little bit lazy because I can't rewrite everything from my server, please ask for further information if needed, such as the script or more logs messages :)










share|improve this question
















I have created a udev rules which is supposed to mount a USB device, backup some datas et cleanup everything. I am actually working on a Debian server.



There is the information about my usb device that I have with lsusb




Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive




(Actually the lsusb returns more Bus / Device, but I have to write them by hand since I am not posting from my Debian machine :))



Then I have written my udev rule called :



10-usb_back.rules


into:



/etc/udev/rules.d/


(I used 95 because the backup script takes some seconds and I want to run it as late as I can for avoiding to delay other stuff)



And finally the rule itself:



ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/mount_usb"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTR{idProduct}=="0243", RUN+="/usr/local/bin/backup_database"


I have tried this too:



ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="054c", ATTR{idProduct}=="0234", RUN+="bash /usr/local/bin/mount_usb"


Unsuccessfully :(



Then I restart udev



sudo /etc/init.d/udev restart


And when I plug my USB device I got this weird message:




[1348.295280] sd 6:0:0:0: [sdc] Assuming drive cache: write through




twice



But nothing happened. No USB device mounted, no data backed up.



I looked with tail -f /var/log/message


And the USB drive looks like detected:



usb 1-3: Product Storage Media 
usb 1-3 Manufacturer Sony`
...


Something must be wrong somewhere but I don't know what, neither where :(



Edit: Since I've been a little bit lazy because I can't rewrite everything from my server, please ask for further information if needed, such as the script or more logs messages :)







debian usb udev






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 17 '13 at 6:18







Edelweiss

















asked May 16 '13 at 8:31









EdelweissEdelweiss

106113




106113













  • You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

    – Kotte
    May 16 '13 at 8:54











  • I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

    – Edelweiss
    May 16 '13 at 9:09











  • Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

    – Kotte
    May 16 '13 at 9:31











  • I had the same problem a while ago. Mabye that solution will work for you too.

    – user13742
    May 16 '13 at 12:51











  • @don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

    – Edelweiss
    May 17 '13 at 6:50





















  • You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

    – Kotte
    May 16 '13 at 8:54











  • I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

    – Edelweiss
    May 16 '13 at 9:09











  • Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

    – Kotte
    May 16 '13 at 9:31











  • I had the same problem a while ago. Mabye that solution will work for you too.

    – user13742
    May 16 '13 at 12:51











  • @don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

    – Edelweiss
    May 17 '13 at 6:50



















You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

– Kotte
May 16 '13 at 8:54





You can use the command at raftaman.net/?p=343 to check for more information on the usb drive. Also, the C program on the bottom of kernel.org/doc/pending/hotplug.txt is really useful for listening to uevents, which makes it easier to see what information you can use. Could also be as simple as some earlier rule is declared as final rule.

– Kotte
May 16 '13 at 8:54













I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

– Edelweiss
May 16 '13 at 9:09





I will take a look at the C program, but it's looks like a little bit tricky, isn't it?

– Edelweiss
May 16 '13 at 9:09













Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

– Kotte
May 16 '13 at 9:31





Somewhat, but you don't need to understand it. It is useful as a util :). Btw, I think you misspelled ATTR, should be ATTRS for usb properties.

– Kotte
May 16 '13 at 9:31













I had the same problem a while ago. Mabye that solution will work for you too.

– user13742
May 16 '13 at 12:51





I had the same problem a while ago. Mabye that solution will work for you too.

– user13742
May 16 '13 at 12:51













@don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

– Edelweiss
May 17 '13 at 6:50







@don_crissti After running udevadm test --action --add /dev/sdc1 (I dont have a devpath directory, I guess devpath is the usb device path?) I had a list of rules, but mine didnt appear and I got a unable to open device '/sys/dev/sdc1'

– Edelweiss
May 17 '13 at 6:50












4 Answers
4






active

oldest

votes


















1














You have misspelled ATTR, it should be ATTRS in this case.






share|improve this answer
























  • Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

    – Edelweiss
    May 16 '13 at 9:37






  • 1





    Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

    – Kotte
    May 16 '13 at 9:40











  • Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

    – Kotte
    May 16 '13 at 9:41











  • I restarted the local server, shall I retart udev too?

    – Edelweiss
    May 16 '13 at 9:45











  • If you restarted the computer, then udev was already restarted.

    – Kotte
    May 16 '13 at 9:47



















0














Aren't those typos in the idProduct portion of the rules?



You have this:



ATTR{idProduct}=="0234"


Shouldn't it be this:



ATTR{idProduct}=="0243"


Based on the output from this line:



Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive





share|improve this answer
























  • You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

    – Edelweiss
    May 16 '13 at 9:33





















0














Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.



Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)






share|improve this answer































    0














    This is my working udev rule for executing backup on hotplug:



    SUBSYSTEM=="block" ACTION=="add" 
    ENV{DEVTYPE}=="partition"
    ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    TAG+="store"
    RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"


    Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.



    On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:



    udevadm test /sys/dev/block/8:65


    to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also



    udevadm info --query=property /dev/sde1


    was helpful to see if my rules are applied, and



    NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f76035%2fudev-rule-not-working%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      1














      You have misspelled ATTR, it should be ATTRS in this case.






      share|improve this answer
























      • Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

        – Edelweiss
        May 16 '13 at 9:37






      • 1





        Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

        – Kotte
        May 16 '13 at 9:40











      • Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

        – Kotte
        May 16 '13 at 9:41











      • I restarted the local server, shall I retart udev too?

        – Edelweiss
        May 16 '13 at 9:45











      • If you restarted the computer, then udev was already restarted.

        – Kotte
        May 16 '13 at 9:47
















      1














      You have misspelled ATTR, it should be ATTRS in this case.






      share|improve this answer
























      • Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

        – Edelweiss
        May 16 '13 at 9:37






      • 1





        Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

        – Kotte
        May 16 '13 at 9:40











      • Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

        – Kotte
        May 16 '13 at 9:41











      • I restarted the local server, shall I retart udev too?

        – Edelweiss
        May 16 '13 at 9:45











      • If you restarted the computer, then udev was already restarted.

        – Kotte
        May 16 '13 at 9:47














      1












      1








      1







      You have misspelled ATTR, it should be ATTRS in this case.






      share|improve this answer













      You have misspelled ATTR, it should be ATTRS in this case.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered May 16 '13 at 9:30









      KotteKotte

      1,5071323




      1,5071323













      • Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

        – Edelweiss
        May 16 '13 at 9:37






      • 1





        Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

        – Kotte
        May 16 '13 at 9:40











      • Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

        – Kotte
        May 16 '13 at 9:41











      • I restarted the local server, shall I retart udev too?

        – Edelweiss
        May 16 '13 at 9:45











      • If you restarted the computer, then udev was already restarted.

        – Kotte
        May 16 '13 at 9:47



















      • Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

        – Edelweiss
        May 16 '13 at 9:37






      • 1





        Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

        – Kotte
        May 16 '13 at 9:40











      • Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

        – Kotte
        May 16 '13 at 9:41











      • I restarted the local server, shall I retart udev too?

        – Edelweiss
        May 16 '13 at 9:45











      • If you restarted the computer, then udev was already restarted.

        – Kotte
        May 16 '13 at 9:47

















      Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

      – Edelweiss
      May 16 '13 at 9:37





      Don't know why, but it still no working, I losing any hope for making this stuff working :( Thank you for your contribution

      – Edelweiss
      May 16 '13 at 9:37




      1




      1





      Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

      – Kotte
      May 16 '13 at 9:40





      Writing udev rules is a very unforgiving task, the slightest error and nothing will happen. Have you tried moving your rule to the beginning of the list? i.e., rename the file to 10-local.rules

      – Kotte
      May 16 '13 at 9:40













      Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

      – Kotte
      May 16 '13 at 9:41





      Also did you restart udev after making changes? udev should react to changes in the settings, but that require inotify to be enabled in the kernel. That might not be the case in embedded systems and the like.

      – Kotte
      May 16 '13 at 9:41













      I restarted the local server, shall I retart udev too?

      – Edelweiss
      May 16 '13 at 9:45





      I restarted the local server, shall I retart udev too?

      – Edelweiss
      May 16 '13 at 9:45













      If you restarted the computer, then udev was already restarted.

      – Kotte
      May 16 '13 at 9:47





      If you restarted the computer, then udev was already restarted.

      – Kotte
      May 16 '13 at 9:47













      0














      Aren't those typos in the idProduct portion of the rules?



      You have this:



      ATTR{idProduct}=="0234"


      Shouldn't it be this:



      ATTR{idProduct}=="0243"


      Based on the output from this line:



      Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive





      share|improve this answer
























      • You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

        – Edelweiss
        May 16 '13 at 9:33


















      0














      Aren't those typos in the idProduct portion of the rules?



      You have this:



      ATTR{idProduct}=="0234"


      Shouldn't it be this:



      ATTR{idProduct}=="0243"


      Based on the output from this line:



      Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive





      share|improve this answer
























      • You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

        – Edelweiss
        May 16 '13 at 9:33
















      0












      0








      0







      Aren't those typos in the idProduct portion of the rules?



      You have this:



      ATTR{idProduct}=="0234"


      Shouldn't it be this:



      ATTR{idProduct}=="0243"


      Based on the output from this line:



      Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive





      share|improve this answer













      Aren't those typos in the idProduct portion of the rules?



      You have this:



      ATTR{idProduct}=="0234"


      Shouldn't it be this:



      ATTR{idProduct}=="0243"


      Based on the output from this line:



      Bus 001 Device 003: ID 054c:0243 Sony Corp. MicroVault Flash Drive






      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered May 16 '13 at 9:18









      slmslm

      250k66527684




      250k66527684













      • You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

        – Edelweiss
        May 16 '13 at 9:33





















      • You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

        – Edelweiss
        May 16 '13 at 9:33



















      You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

      – Edelweiss
      May 16 '13 at 9:33







      You got a point, i fixed it but still not working, anyway thanks for pointing that out :)

      – Edelweiss
      May 16 '13 at 9:33













      0














      Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.



      Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)






      share|improve this answer




























        0














        Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.



        Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)






        share|improve this answer


























          0












          0








          0







          Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.



          Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)






          share|improve this answer













          Try having a look at the output for udevadm info --path=path/to/device --attribute-walk It will tell you every attribute and subsystem that's valid for the device. For instance, a USB device I have has a SUBSYSTEM="tty", to recognize USB for that device you need to put SUBSYSTEMS=="usb" (note: plural subsystem*s*). I suspect that something like that may be the case here. Either way udevadm info --attribute-walk is a really helpful tool for debugging udev problems.



          Also ATTR{key} is not valid, instead use ATTRS{key} (It was mentioned before, but some of your examples still use the incorrect form.)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jun 12 '13 at 20:26









          isidor3isidor3

          3116




          3116























              0














              This is my working udev rule for executing backup on hotplug:



              SUBSYSTEM=="block" ACTION=="add" 
              ENV{DEVTYPE}=="partition"
              ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
              TAG+="store"
              RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"


              Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.



              On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:



              udevadm test /sys/dev/block/8:65


              to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also



              udevadm info --query=property /dev/sde1


              was helpful to see if my rules are applied, and



              NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.






              share|improve this answer




























                0














                This is my working udev rule for executing backup on hotplug:



                SUBSYSTEM=="block" ACTION=="add" 
                ENV{DEVTYPE}=="partition"
                ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
                TAG+="store"
                RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"


                Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.



                On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:



                udevadm test /sys/dev/block/8:65


                to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also



                udevadm info --query=property /dev/sde1


                was helpful to see if my rules are applied, and



                NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.






                share|improve this answer


























                  0












                  0








                  0







                  This is my working udev rule for executing backup on hotplug:



                  SUBSYSTEM=="block" ACTION=="add" 
                  ENV{DEVTYPE}=="partition"
                  ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
                  TAG+="store"
                  RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"


                  Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.



                  On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:



                  udevadm test /sys/dev/block/8:65


                  to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also



                  udevadm info --query=property /dev/sde1


                  was helpful to see if my rules are applied, and



                  NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.






                  share|improve this answer













                  This is my working udev rule for executing backup on hotplug:



                  SUBSYSTEM=="block" ACTION=="add" 
                  ENV{DEVTYPE}=="partition"
                  ENV{ID_FS_UUID}=="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
                  TAG+="store"
                  RUN+="/usr/bin/python3 /etc/systemd/autoback.py --udev"


                  Note that instead of matching the USB device, I'm matching a partition (i.e. /dev/sde1) on the mass storage endpoint of that usb device. It takes a few seconds after the USB hotplug before the disk is ready and the partition is enumerated so this is the "right" event for my use case, and probably yours too if you're trying to do backups. ID_FS_UUID is the same as reported by blkid for this partition. In my case, this is the luks UUID.



                  On my system udev doesn't seem to automatically reload correctly when I edit rules, but what I've found to work (which is also useful for debugging) is:



                  udevadm test /sys/dev/block/8:65


                  to force a reload/re-application of udev rules. Note that I found 8:65 by ls -l /dev/block | grep sde1. Also



                  udevadm info --query=property /dev/sde1


                  was helpful to see if my rules are applied, and



                  NOTE: I'm posting this answer 5 years after the OP, so things might be different now than then. My system is ubuntu 16.04.4 (xenial) on arm64.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 15 mins ago









                  cheshirekowcheshirekow

                  1362




                  1362






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f76035%2fudev-rule-not-working%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Accessing regular linux commands in Huawei's Dopra Linux

                      Can't connect RFCOMM socket: Host is down

                      Kernel panic - not syncing: Fatal Exception in Interrupt