[gelöst] udev: Rückgabewert von ps im Skript, bug?

[detix]

Für ein automatisches backup auf einer USB-Festplatte, habe ich mir eine kleine Regel geschrieben, die auf Nachfrage ein Skript ausführt und das funktioniert so auch.
In einer while -Schleife werden 2 im Hintergrund ausgeführte rsync Befehle mit ps aufs Vorhanden geprüft:

Code: Alles auswählen

while ps -p $rsync1Pid || ps -p $rsync2Pid; do ...

und darin eine Progressbar entsprechend aktualisiert, nur scheinen genau diese Rückgabewerte nicht zu funktionieren, die Schleife wird ab einem gewissen Umfang (200MB geht, 1GB nicht mehr) nicht mehr verlassen, sie wird zur Endlosschleife!

Code: Alles auswählen

while ps --no-headers -p $rsync1Pid || ps --no-headers -p $rsync2Pid; do ...

dagegen funktioniert, wird also wenn durch udev gestartet nicht der Rückgabewert von ps berücksichtigt, sondern nur auf Inhalt geprüft?
Das wäre doch ein bug, oder habe ich hier einen Denkfehler?
Ein relativ identisches Skript (nicht durch udev gestartet) auf ein debian-NAS losgelassen funktioniert dagegen...

[rendegast]

Sind die beiden backups sehr unterschiedlich?
Eventuell wird die PID des (sehr viel) früher fertigen Jobs wiederverwendet (dauerhaft).


Du könntest Lock-Dateien an den jeweiligen backup-Job binden:

Code: Alles auswählen

#!/bin/sh

LK1=$(tempfile)
LK2=$(tempfile)

{ sleep 15 && rm $LK1; } &
{ sleep 10 && rm $LK2; } &

BAR="#"
while ls $LK1 >/dev/null 2>&1 || ls $LK2 >/dev/null 2>&1; do
    echo -n "$BAR"
    sleep 1
done

[detix]

Eventuell wird die PID des (sehr viel) früher fertigen Jobs wiederverwendet

Das könnte es sein, und je mehr ich darüber nachdenke wird es wohl so sein, darauf wäre ich nach zig Tests im Leben nicht mehr gekommen!
Es stimmt schon, für meine Tests habe ich nur einen der beiden rsync-Befehle in Anspruch genommen, natürlich den der zuerst läuft , der 2te bekam eine höhere Pid die aber schnell wieder frei war...
Ich darf also nicht nur auf die Pids testen, sondern auch ob diese Pids zu rsync gehören!
Vielleicht noch einfacher, mit

Code: Alles auswählen

ps -C rsync

testen ob da noch was läuft, spart mir sogar das "oder" in der while Schleife, mehr rsync wird es gleichzeitig nicht geben.
Also doch kein bug, sondern ein riesiger Denkfehler meinerseits...
Werde das wahrscheinlich erst am Wochenende durchtesten, aber das wird die Lösung sein, vielen Dank rendegast!

[rendegast]

ps -C rsync

Da schien mir pgrep geeigneter,
was jedoch komplexe Suchmuster erfordern könnte, um sicher zu sein
(gegebenenfalls 'hidepid=1' für /proc).
Sicherer und unkomplizierter ist da immer noch die Lockfile-Lösung.

[detix]

Irgendwie möchte ich jetzt ganz weit ausholen, kann es aber nicht in Worte fassen...
Fest steht schonmal das udev unschuldig ist!
Dein Skript scheint mir auch die absolut optimale Lösung zu sein, nicht funktioniert hat zB:

Code: Alles auswählen

while ps -C rsync; do...

die Schleife wird auch hier zur Endlosschleife!

Wo ich mir zu 100% sicher war das es geht:

Code: Alles auswählen

while ps -p $rsync1Pid,$rsync2Pid | grep rsync; do...

tuts auch nicht, die Schleife wird vorzeitig verlassen obwohl rsync noch läuft!
Irgendwas macht hier was es will, keine Ahnung...

Was mit deinem Hinweis scheinbar auch richtig ist, zumindest waren bisherige Versuche damit erfolgreich:

Code: Alles auswählen

while pgrep -x rsync; do...

läuft bei meinen Tests (mit 14MB - 3GB Volumen) völlig problemlos, werd ich erstmal so beibehalten.

[habakug]

Hallo!

Hier nimmt ps -p nur eine PID, auch mit Komma getrennt oder anderen Tricks.
Andere Idee:

Code: Alles auswählen

$ sync & sync & wait %1 %2
[1] 11569
[2] 11570
[1]-  Fertig                  sync
[2]+  Fertig                  sync

Funktioniert nur, wenn alles in einer Shell bleibt.

Gruss, habakug

edit:
Geht doch:

Code: Alles auswählen

$ ps -p "2424 2437"
  PID TTY          TIME CMD
 2424 pts/1    00:00:00 bash
 2437 pts/2    00:00:00 bash

[rendegast]

Code: Alles auswählen

$ ps -p 17785,17790
  PID TTY          TIME CMD
17785 ?        00:00:00 pulseaudio
17790 ?        00:00:00 gconfd-2

$ ps -p 17785 17790
  PID TTY      STAT   TIME COMMAND
17785 ?        Sl     0:00 /usr/bin/pulseaudio --start
17790 ?        S      0:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2

$ ps -p "17785 17790"
  PID TTY          TIME CMD
17785 ?        00:00:00 pulseaudio
17790 ?        00:00:00 gconfd-2$ ps -p 17785,17791



# Bsp mit einer nichtverwendeten pid
$ ps -p 17785,17791 ; echo $?
  PID TTY          TIME CMD
17785 ?        00:00:00 pulseaudio
0
$ ps -p 17785 17791 ; echo $?
  PID TTY      STAT   TIME COMMAND
17785 ?        Sl     0:00 /usr/bin/pulseaudio --start
0
$ ps -p "17785 17791" ; echo $?
  PID TTY          TIME CMD
17785 ?        00:00:00 pulseaudio
0

# Bsp mit zwei nichtverwendeten pid
$ ps -p 17786,17791 ; echo $?
  PID TTY          TIME CMD
1
$ ps -p 17786 17791 ; echo $?
  PID TTY      STAT   TIME COMMAND
1
$ ps -p "17786 17791" ; echo $?
  PID TTY          TIME CMD
1

Naja, 'ps' halt,
In 'man ps' wird eine nicht näher beschriebene "pidlist" eingesetzt.

[detix]

Ich verstehe eure beiden Posts nur sehr bedingt, habe aber mal versucht ein Beispiel zu geben:
2 Ordner in $HOME erstellen:

Code: Alles auswählen

mkdir ~/temp1 ~/temp2

Es soll von temp1 nach temp2 "rsynct" werden, wegen der Größe gehts nur um kleine Dateien die aber zeitlich durch rsync Parameter "--bwlimit=" in die Länge gezogen werden,
das Erstellen dieser Dateien in ~/temp1/ (d1-3) erfolgt mit:

Code: Alles auswählen

cd ~/temp1
base64 /dev/urandom | dd of=d1 bs=1k count=300 #300k Größe, fürs Testen bitte hier die Größe variieren...
base64 /dev/urandom | dd of=d2 bs=1k count=50 #50k Größe
base64 /dev/urandom | dd of=d3 bs=1k count=20 #20k Größe

Ein gelabelter USB-Stick (backup_usbstick) soll dann nach dem Einstöpseln ein Skript ausführen,
die entsprechende udev-Regel sieht hier so aus, der Stick selbst dient nur als Auslöser:

KERNEL=="sd[g-i]1", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="backup_usbstick", ACTION=="add", \
RUN+="/bin/su -c '/usr/local/bin/pn_backup_usbstick %k %E{ID_FS_LABEL}' detix"

das Skript, gespeichert in "/usr/local/bin/pn_backup_usbstick" würde damit als user "detix" ausgeführt, Inhalt:

Code: Alles auswählen

#!/bin/bash
echo "rsync Test" >/tmp/rsync

rsync --bwlimit=10k -a ~/temp1/{d1,d2} ~/temp2 & rsync1Pid=$! #d1+d2=350k, dauert ca 35s mit bwlimit=10k
rsync --bwlimit=1k -a ~/temp1/d3 ~/temp2 & rsync2Pid=$! #d3=20k, dauert ca 20s mit bwlimit=1k

# Beispiele mit while, kommentiert mit oder ohne Erfolg:
#while ps -p $rsync1Pid,$rsync2Pid | grep rsync; do #geht, zumindest bis zu einer gewissen Dateigröße <=100kb? Darüber wird die Schleife vorzeitig verlassen
#while ps -p $rsync1Pid,$rsync2Pid | grep -q rsync; do #geht, zumindest mit diesem Skript perfekt
#while ps -C rsync; do #geht, zumindest bis zu einer gewissen Dateigröße <=100kb? Sonst Endlosschleife
#while ps -C rsync &>/dev/null; do #geht, perfekt
while pgrep -x rsync; do #geht, perfekt
  echo -n "rsync läuft noch $rsync1Pid,$rsync2Pid " >>/tmp/rsync
  date +'%M:%S' >>/tmp/rsync # Start- Stoppzeit, Minute:Sekunde
  sleep 1
done
echo "fertig" >>/tmp/rsync

Es sieht so aus, das eine Umlenkung, zB bei "ps -C rsync", nach /dev/null und auch bei
ps -p $rsync1Pid,$rsync2Pid | grep -q rsync, hier natürlich das "-q" eine wesentliche Rolle spielt!

[rendegast]

Es sieht so aus, das eine Umlenkung, zB bei "ps -C rsync", nach /dev/null und auch bei
ps -p ... | grep ...

Eigentlich reicht
code/------------------------
while ps -p $pid1,$pid2 >/dev/null; do .....
----------------------/code
EDIT, falsch, soll ja ein Konstrukt sein, ob die PID tatsächlich noch rsync-Prozesse darstellen
(mit der Annahme, daß es die richtigen wären.
Besser wäre etwas in Richtung Lock-Dateien. Eineindeutig.).

echo -n "rsync läuft noch $rsync1Pid,$rsync2Pid " >>/tmp/rsync
date +'%M:%S' >>/tmp/rsync # Start- Stoppzeit, Minute:Sekunde

verkürzt

Code: Alles auswählen

date "+%F %T rsync läuft noch $(pidof rsync)" >>/tmp/rsync

[detix]

Eigentlich reicht

Code: Alles auswählen

while ps -p $pid1,$pid2 >/dev/null; do .....

Das widerspricht sich aber mit deiner og Aussage:

Eventuell wird die PID des (sehr viel) früher fertigen Jobs wiederverwendet (dauerhaft).

Nur, um das mal zum Ende zu bringen:
Ich habe mich letztendlich für diese Variante entschieden und die funktioniert bisher auch perfekt (USB-HD und NAS):

Code: Alles auswählen

while ps -p $rsync1Pid,$rsync2Pid | grep -q rsync; do...

Problem gelöst, ob es an der eigenen Dummheit lag muss ich allerdings offen lassen...

[rendegast]

ps -p ... | grep ...

Eigentlich reicht
while ps -p $pid1,$pid2 >/dev/null; do .....

Das widerspricht sich aber mit deiner og Aussage:

Fauxpas,
habe in dem Moment nur an die Form gedacht, ein hinreichendes exit0/exit1 zu erhalten,
nicht an die Kontrolle auf tatsächlichen rsync-Prozeß.

[detix]

Nein, nix Fauxpas!
Du hast mir schon die zielführenden Tipps gegeben!