[Bash] sudo in while-loop geeft raar gedrag

[Sando]

Ik wil veranderingen in een bepaalde directory automatisch syncen naar een andere directory en heb daarvoor een simpel scriptje gemaakt die precies doet wat het moet doen:

Bash:

Delphi:

#!/usr/bin/env bash
inotifywait -m -r --format '%w%f' -e modify -e move -e create -e delete /var/test | while read line; do
    rsync -ah --del --progress --stats --update "$line" "/home/test/" 
done

Echter wil ik dit als een gewone gebruiker (mezelf) uitvoeren, en heb daartoe rsync aan sudoers toegevoegd. Nu werkt sudo rsync ook zonder een wachtwoord in te voeren.

Maar wat schetst mijn verbazing, het script (alleen sudo toegevoegd):
Bash:

Delphi:

#!/usr/bin/env bash
inotifywait -m -r --format '%w%f' -e modify -e move -e create -e delete /var/test | while read line; do
    sudo rsync -ah --del --progress --stats --update "$line" "/home/test/" 
done

flipt helemaal als er een inotify event binnenkomt! Het rsync commando wordt nonstop oneindig maal achter elkaar uitgevoerd. Dit gebeurt zo snel dat het bijna onmogelijk is om er een Ctrl+C tussen te krijgen.

Ik snap de logica niet. Wie kan me vertellen waarom dit gebeurt en hoe ik het krijg zoals het zonder sudo werkt, gewoon één event is code één keer uitvoeren?

(Note: Er is geen shellscript color coding daarom maar even pascal gekozen. )

[ Voor 5% gewijzigd door Sando op 29-12-2012 10:50 ]

[NMe]

Waar hoort mijn topic?

PRG>>NOS

[Matis]

Wat het probleem is weet ik niet, maar wat gebeurt er als je het script als sudo uitvoert en de sudo-regel binnen de inotifywait laat vervallen?
Daarnaast kan het geen kwaad om de exit status van inotifywait te controleren voordat je er een vervolgactie aan ophangt.

quote: http://linux.die.net/man/1/inotifywait

1. The program executed successfully, and an event occurred which was being listened for.
2. An error occurred in execution of the program, or an event occurred which was not being listened for. The latter generally occurs if something happens which forcibly removes the inotify watch, such as a watched file being deleted or the filesystem containing a watched file being unmounted.
3. The -t option was used and an event did not occur in the specified interval of time.

Ik vind het een interessant probleem; Heb je nog een specifieke Linux-distro? Want ik wil het anders wel een proberen te reproduceren

Edit; Net even getest op Ubuntu 12.04-1 (up2date) en daar werkt het gewoon "naar" behoren.
Ik vrees dat het probleem hem zit in de read line, die je hebt opgenomen in de while clausule. Misschien dat je het zo kunt oplossen

code:

while 1 do
  while inotifywait do
    rsync
  done
deone

[ Voor 13% gewijzigd door Matis op 29-12-2012 13:31 ]

[Sando]

Bij jou werkt het naar behoren? Heb je het met èn zonder sudo geprobeerd? Want ik heb het bizarre probleem stelselmatig, het was geen toevalstreffer.

Er is wat gedoe waardoor ik het script niet kan/wil starten met sudo. Er zijn dan omgevingsvariabelen en binaries in mijn home die niet gevonden kunnen worden.

Uiteraard kan het wel, maar dan moet er een hoop geklooi gebeuren, en ik wil uiteraard gewoon dat het werkt zoals ik wil, en kan er natuurlijk als een echte tweaker niet tegen dat ik niet begrijp waarom hij aan één stuk door gaat.

Het lijkt wel alsof sudo rsync opeens non-blocking is en hij blijft proberen te starten tot ie opeens blocking wordt ofzo.

Ik gebruik Linux Mint 14 Cinnamon, dat is gebaseerd op Ubuntu 12.10.

inotify draait indefinitely en geeft dus geen exitstatus. De voorgestelde loop kan ik niet vervangen. Met while inotifywait do ipv readlinekan ik niet opvangen welke bestanden affected zijn, of is daar een andere manier voor?

[ Voor 26% gewijzigd door Sando op 29-12-2012 17:27 ]

[Sando]

Ik kreeg zo'n *ploep random idee* en ik heb iets interessants ontdekt.

Originele script dat rsync rapid-fire'd:

Delphi:

#!/usr/bin/env bash
inotifywait -m -r --format '%w%f' -e modify -e move -e create -e delete /var/test | while read line; do
    sudo rsync -ah --del --progress --stats --update "$line" "/home/test/" 
done

Probeersel dat ook rapid-fire'd:

Delphi:

#!/usr/bin/env bash
inotifywait -m -r --format '%w%f' -e modify -e move -e create -e delete /var/test | while read line; do
    sudo sh -c 'rsync -ah --del --progress --stats --update "$line" "/home/test/"'
done

Probeersel die wel doet wat we verwachten:

Delphi:

#!/usr/bin/env bash
inotifywait -m -r --format '%w%f' -e modify -e move -e create -e delete /var/test | while read line; do
    sh -c 'sudo rsync -ah --del --progress --stats --update "$line" "/home/test/"'
done

Ik heb dus nu een 'workaround' gevonden, maar ik snap niet wat er nu gebeurt.

[MartinMeijerink]

Ik denk dat het met timing te maken heeft. Ik denk dat het proces dat iets in /var/test doet, dit niet in 1 klap doet, maar in kleine beetjes (misschien letter voor letter in plaats van een hele regel).
Het probeersel wat niet doet wat je verwacht merkt misschien elke kleine verandering op, en wil daarom zo vaak rsync starten.
Bij het probeersel wat wel doet wat je verwacht spawn je een hele nieuwe shell en veroorzaak je wat meer overhead, zodat dat wat 1 verandering moet zijn, ook echt als 1 verandering gezien wordt.

_{(Overigens wil ik nog opmerken dat het niet handig is om rsync in je sudoers te zetten, zo kan iemand onder jouw naam wel heel makkelijk root worden door iets naar /etc/shadow te rsyncen)}

[FitzJac]

Waar je probleem ligt weet ik ook niet, maar ik gebruik voor hetzelfde doeleind lsyncd, nog nooit enig gezeur gehad.
http://code.google.com/p/lsyncd/

[Sando]

@MartinMeijerink: maar dan zou je dat toch ook bij de niet-sudo en de sudo-voor-sh ipv andersom moeten zien?

MartinMeijerink schreef op zaterdag 29 december 2012 @ 20:29:
Overigens wil ik nog opmerken dat het niet handig is om rsync in je sudoers te zetten, zo kan iemand onder jouw naam wel heel makkelijk root worden door iets naar /etc/shadow te rsyncen

Aanvankelijk wilde ik gewoon zo min mogelijk irrelevante informatie geven, maar ik heb de mogelijkheden uiteraard wel wat begrensd. Uit mijn hoofd weet ik het niet meer, maar er staat iets wat lijkt op:

code:

redsandro ALL=(ALL:ALL) NOPASSWD: /bin/rsync * [/home|/var|/tmp]/* /home/*

@FitzJac: Hey die tool ken ik niet, klinkt wel interessant. Het doet ongeveer wat ik probeer te doen. Maar ik wil eerst local rsyncen naar een encfs of ecryptfs map. En dan de bronmap daarvan weer remote syncen, zodat mijn bestanden voor derden niet leesbaar zijn. Dat (remote rsyncen) doe ik nu handmatig aan het einde van de dag, maar het liefst zet ik daar ook een inotify op. Of lsyncd die je noemt. Maar dat werkt ook met inotify. En hoewel de gelinkte pagina het syncen van home als voorbeeld geeft heb ik daar zo'n 50000 subdirectories in staan, terwijl de limiet van inotify op 8092 watches staat. Dat kan je wel opvoeren, maar ik vraag me af wat dat met de performance doet.

Doe jij iets met encryptie? Ben wel nieuwschierig naar je aanpak dan.

Daarnaast vond ik OwnCloud wel een geniale open source dropbox achtige variant, maar de encryptiemodule is decrepated omdat OwnCloud 5.0 dat native gaat ondersteunen (terwijl die voorlopig nog niet uit is, erg irritant). Ook is het geniaal voor kleine mapjes, maar als ik mijn complete home ga delen dan is dat ding 100x zo lang bezig als rsync en gebruikt ie wel een gigabyte geheugen. Onbruikbaar dus. Jammer dat iets waar duidelijk heel veel werk in is gestoken al snel onbruikbaar is. Als het alleen lekker werkt voor kleine mappen dan kan je net zo goed Dropbox gebruiken.

Gefeliciteerd met je verjaardag trouwens!

[H!GHGuY]

Als "sh -c 'sudo ...' " wel werkt dan ligt het vrijwel zeker aan environment variabelen.

Doe eens een 'env | sort' ertussen en vergelijk met je normale environment.

[Sando]

Dan zou het toch niet moeten uitmaken of ik nu sudo blaat of sh -c sudo blaat doe?
Anyway ik zal eens kijken naar de environment als ik weer op kantoor ben.

[Hero of Time]

Ik vraag mij wel af waarom je #!/usr/bin/env bash gebruikt, ipv #!/bin/bash.

[Sando]

env zit vrijwel altijd in /usr/bin, bash zit niet altijd in /bin.

[Hero of Time]

Bash heb je altijd op Linux, dus om 't niet via #!/bin/bash te doen, is geen reden. Mocht bash toch niet in /bin staan, dan is een simpele 'which bash' voldoende om z'n pad te vinden en die te gebruiken. En anders kan je altijd nog /bin/sh gebruiken wat voor dit script niets uit zal maken

Enne, gelukkig nieuwjaar

[Sando]

Dat zal, maar ik had ooit een script in Linux gemaakt wat het niet in OpenBSD deed. Terwijl dat ook gewoon bash heeft.

Dus ik googlen en leren dat /usr/bin/env een veel gebruikte shebangtruuk is om je scripts portable te houden. En nu zet ik dat sinds jaar en dag in de shebang, ookal is het voor een lokaal script die niet perse portable hoeft te zijn niet direct nodig, het is gewoon een best practice.

Dusseh, gelukkig nieuw jaar en dan bij deze een gratis tip.

sh is trouwens ook een no-go, 9 van de 10 variable-truuks die je doet in bash werken niet in sh.
Mijn werkelijke script is een stuk groter, maar de laatste keer dat ik een paar extra regels die niet direct relevant aan de code waren postte op tweakers werd mijn topic vrij rap gesloten, dus ik heb het even zo minimaal mogelijk gehouden.

[ Voor 26% gewijzigd door Sando op 01-01-2013 03:56 ]

[H!GHGuY]

Sando schreef op maandag 31 december 2012 @ 09:47:
Dan zou het toch niet moeten uitmaken of ik nu sudo blaat of sh -c sudo blaat doe?
Anyway ik zal eens kijken naar de environment als ik weer op kantoor ben.

Ik zou er de man pages nog even moeten op naslaan, maar volgens mij doet:
- sudo X: gebruikt de environment variabelen van het calling script
- sh -c "sudo X": gebruikt de environment variabelen van het calling script + draait de shell rc scripts

[FitzJac]

@Redsandro: Dank je wel

Ik gebruik dat lsyncd icm met Unison http://www.cis.upenn.edu/...stable/unison-manual.html
Dus het syncen gaat met Unison wat over ssh werkt. Het enige nadeel van Unison is, is dat zowel de client als de server de zelfde versie moeten draaien anders werkt het niet.
Ben overigens ooit op dit idee gekomen omdat er toendertijd veel over Dropbox veiligheids-issues te lezen was. Maar ik hou maar 1 directory met een aantal sub-directories in sync, dus over performance kan ik je niet veel vertellen.

[ Voor 45% gewijzigd door FitzJac op 02-01-2013 20:31 ]