[Linux] udevadm probleempje

[Anoniem: 279559]

Al enige tijd ben ik aan het sukkelen om een automatische back-up gedaan te krijgen met udevadm maar dit lukt me niet helemaal.

Wat eigenlijk het einddoel is, is het volgende: er wordt een usb-hd in men linux bak gestoken en automatisch wordt een bepaalde directory gebackupped ernaar. Zodra de back-up klaar is, wordt er een mailtje gestuurd zodat je weet dat het proces klaar is en kan je je usb-hd verwijderen en ergens offsite bijhouden.
Het schrijven van een bash-script voor het back-uppen werkt al. Het probleem zit hem in het weten wanneer de usb-hd ingestoken wordt en het script ge-runt moet worden.

Om dit event op te vangen maak ik gebruik van udevadm. Concreet heb ik een extra filetje bijgemaakt /etc/udev/rules.d/81-backup.rules met de volgende inhoud:

code:

ACTION=="add", ATTRS{serial}=="2A07070658766", RUN+="/home/gjc/backup_script/test.sh"

Ik heb gekozen voor deze rule op nr. 81 te zetten zodat er niet belangrijks wordt overgeschreven wat misschien in vorige regels staat. Het bash script wat er nu normaal gerunt moet worden doet niets anders als dit:

code:

 #!/bin/sh
touch /home/gjc/backup_script/done.txt

Dus even gewoon laten zien dat het uitgevoerd is.

De info over mijn usb-device heb ik opgevraagd met: udevadm info -a -p $(udevadm info -q path -n /dev/sdb) dit gaf als resultaat: http://pastebin.com/2JSY1NFW.

Voor de filter regel in /etc/udev/rules.d/81-backup.rules heb ik al met veel verschillend combinaties zitten experimenten maar nog altijd match te regel precies niet.
Volgens mij is het probleem dat de filter regel niet ondubbelzinnig is en hij daarom niet matcht. Het lezen van dingen zoals http://reactivated.net/writing_udev_rules.html heeft met ook niet veel verder geholpen. Tevens is er voor mijn onduidelijkheid welke nummer de regel nu moet hebben (81 atm)?

Alvast bedankt

[swbr]

Just in case, is je script wel executable gemaakt met chmod?

Verder zou je kunnen testen door simpelweg de regel die staat bij http://reactivated.net/wr...rules.html#example-usbhdd te copy/pasten. Die zal in de meeste gevallen netjes een symlink onder /dev/ neer moeten zetten als je je hdd inplugt.

[Anoniem: 279559]

Antaresje schreef op woensdag 20 februari 2013 @ 13:51:
Just in case, is je script wel executable gemaakt met chmod?

Ja het script heeft de execute flag. Als ik dit run:

code:

 sh /home/gjc/backup_script/test.sh

werkt het gewoon en wordt het bestandje done.txt aangemaakt.

Antaresje schreef op woensdag 20 februari 2013 @ 13:51:
Verder zou je kunnen testen door simpelweg de regel die staat bij http://reactivated.net/wr...rules.html#example-usbhdd te copy/pasten. Die zal in de meeste gevallen netjes een symlink onder /dev/ neer moeten zetten als je je hdd inplugt.

Bedankt voor dit antwoord. Met behulp van dit voorbeeld heb ik al een werkende regel kunnen maken nl:

code:

ACTION=="add", KERNEL=="sd*", SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Sony", ATTRS{product}=="Storage Media", ATTRS{serial}=="2A07070658766", SYMLINK+="backuphd", RUN+="/home/gjc/backup_script/test.sh"

De symlink wordt gemaakt in /dev/backuphd als ik men usb device erin plug. Dus volgens mij match de regel wel succesvol.
Enkel het shell script geeft nog helemaal geen teken van leven.

[Hero of Time]

Anoniem: 279559 schreef op donderdag 21 februari 2013 @ 11:22:
[...]

Ja het script heeft de execute flag. Als ik dit run:

code:

 sh /home/gjc/backup_script/test.sh

werkt het gewoon en wordt het bestandje done.txt aangemaakt.

...

Enkel het shell script geeft nog helemaal geen teken van leven.

Tja, als ik een bestand maak met de tekst "echo hello world" en ik voer 'm uit via 'sh hoi.sh' werkt 't ook prima. Maar als ik ./hoi.sh probeer, werkt 't niet en krijg ik permission denied taferelen. Doe maar eens ls -l (dat is een kleine L) op de map waar je script staat. Is je bestand groen gekleurd, bevatten de rechten een x, als in -rwx?

Er werd aangegeven dat je naar chmod moest kijken, en dat heb je niet gedaan. Graag ieder advies die je krijgt goed bekijken voordat je zegt dat je er al naar gekeken hebt of dat het 'zo en zo wel werkt'. We zeggen het niet voor niets Zeker voor beginners

[Anoniem: 279559]

Het probleem is opgelost.
Er was blijkbaar helemaal niets mis met de permissies van de bash-scripts. Ze hadden allemaal netjes de juiste opties gekregen. Als ik het script voorzie van een #!/bin/bash in plaats van een #!/bin/sh werkt het wel.
Bedankt voor het meedenken.

[Hero of Time]

Apart, er zou geen verschil moeten zijn tussen sh en bash manier van uitvoeren van een simpele echo. Blijkbaar dus wel. Enige andere waar ik aan denk wat 't zou zijn, is omgevingsvariabelen voor de betreffende shell, in de context waarin 't wordt uitgevoerd.

[Sendy]

Ik zie in de startpost wel een spatie voor de shebang. Ik hoop niet dat dat 't was

De udev documentatie is verrassend duidelijk. Uit http://www.reactivated.ne...v_rules.html#external-run

Be sure to ensure your program is marked executable, if it is a shell script ensure it starts with an appropriate shebang (e.g. #!/bin/sh).

Dus als dat het niet was, dan zou ik een bugrapport indienen

[BoAC]

Waar linkt /bin/sh naartoe?

code:

ls -l /bin/sh

Ik zie die namelijk nogal eens naar iets anders wijzen als bash. En als dat het geval is en je gebruikt een syntax die dan niet ondersteund wordt, gaat je script uiteraard mis

[Anoniem: 279559]

BoAC schreef op vrijdag 22 februari 2013 @ 08:06:
Waar linkt /bin/sh naartoe?

code:

ls -l /bin/sh

Als ik dat uitvoer krijg ik als resultaat:

code:

lrwxrwxrwx 1 root root 4 Feb 19 13:10 /bin/sh -> dash

Ik vermoed dat hier een deel van het probleem gelegen heeft. Het backup-script is niet uit te voeren met #!/bin/sh omdat deze dash gebruikt en hierin blijkbaar een aantal functies niet ondersteund zijn die in bash wel ondersteund zijn.
Het enige vreemde is dan wel dat bij simpelere scripts die wel met #!/bin/sh kunnen runnen helemaal niet opgestart kunnen worden via udev.

Maar er is me nog iets opgevallen tijdens het lezen van http://reactivated.net/writing_udev_rules.html#external-run. Er staat:

... This program can act on the device, however it must not run for any extended period of time, because udev is effectively paused while these programs are running...

Met dit in het achterhoofd lijkt het me niet aangewezen om via de udev regels rechtstreeks het back-up script te runnen omdat dit script potentieel lang kan duren en udev dan dus gepauzeerd is. Dus dacht ik van dit zo op te lossen:
De filter regel veranderen naar: (de %k staat voor de locatie waarop het usb-device te vinden is)

code:

ACTION=="add", ... , RUN+="/home/gjc/backup_script/start_backup.sh %k"

Zodat udev /home/gjc/backup_script/start_backup.sh start waarin het volgende staat:

code:

#!/bin/bash
sleep 1
#Fork off the actual backup script 
sudo /home/gjc/backup_script/backup.sh $1 &

Levert dit eigenlijk het gewenste op? Dat udev start_backup.sh oproept en dat dit script het hoofd-backup script (backup.sh) af forkt?

[ Voor 13% gewijzigd door Anoniem: 279559 op 22-02-2013 09:55 ]

[BoAC]

Zie Google

[Hero of Time]

Dat kan, maar dan moet je niet met sudo werken in je script. Udev rules worden al door root getriggered En mocht 't niet zo zijn, dan staat 't doodleuk op een sudo prompt te wachten, geeft 't 'command not found' (want niet in $PATH) of permission denied - user not in sudoers file.

[Anoniem: 279559]

Hero of Time schreef op vrijdag 22 februari 2013 @ 22:15:
Dat kan, maar dan moet je niet met sudo werken in je script. Udev rules worden al door root getriggered En mocht 't niet zo zijn, dan staat 't doodleuk op een sudo prompt te wachten, geeft 't 'command not found' (want niet in $PATH) of permission denied - user not in sudoers file.

Ah ja inderdaad. Goed opgemerkt, dit soort dingen is gemakkelijk over het hoofd te zien.
Ik moet me eerst nog wat inlezen in linux processen voordat het maken van een daemon en dat soort dingen gaat lukken.

Resultaten volgen nog.