Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Skriptologie
9 views
Skip to first unread message
Paul-Wilhelm Hermsen
May 9, 2013, 8:51:57 AM5/9/13
to
Skriptnovice schreibt:
Ich habe ein Skript folgender Art
Command 1 (Daemon abschalten)
Command 2 (Datensicherung anwerfen)
Command 3 (Daemon anschalten)
Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
recht lange dauert, beendet ist. Und genau das ist mein Problem.
Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
stellen, dass
a) die Datensicherung beendet ist und
b) weil die Datensicherung beendet ist, Command 3 ausgeführt wird.
Die PID von Command 2 hilft mir zur Zeit auch nicht weiter, denn
a) sie ist auch nach abgeschlossener Datensicherung noch existent und
b) wüsste ich jetzt nicht, wie ich sie nach Auslesen durch das Skript
beseitigen lassen könnte, damit z.B. nach eliminierter PID von Command 2
Command 3 in Aktion treten könnte. Außerdem stellt das Auslesen der PID
gemäß a) ja nicht sicher, dass der zugehörige Prozess (Datensicherung)
beendet ist
Alles klar, oder habe ich mich zu verworren ausgedrückt?
Ich habe ein Skript folgender Art
Command 1 (Daemon abschalten)
Command 2 (Datensicherung anwerfen)
Command 3 (Daemon anschalten)
Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
recht lange dauert, beendet ist. Und genau das ist mein Problem.
Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
stellen, dass
a) die Datensicherung beendet ist und
b) weil die Datensicherung beendet ist, Command 3 ausgeführt wird.
Die PID von Command 2 hilft mir zur Zeit auch nicht weiter, denn
a) sie ist auch nach abgeschlossener Datensicherung noch existent und
b) wüsste ich jetzt nicht, wie ich sie nach Auslesen durch das Skript
beseitigen lassen könnte, damit z.B. nach eliminierter PID von Command 2
Command 3 in Aktion treten könnte. Außerdem stellt das Auslesen der PID
gemäß a) ja nicht sicher, dass der zugehörige Prozess (Datensicherung)
beendet ist
Alles klar, oder habe ich mich zu verworren ausgedrückt?
Marc Haber
May 9, 2013, 9:10:03 AM5/9/13
to
Paul-Wilhelm Hermsen <p...@bisskultur.de> wrote:
>Ich habe ein Skript folgender Art
>
>Command 1 (Daemon abschalten)
>Command 2 (Datensicherung anwerfen)
>Command 3 (Daemon anschalten)
>
>Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
>recht lange dauert, beendet ist. Und genau das ist mein Problem.
Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
>Ich habe ein Skript folgender Art
>
>Command 1 (Daemon abschalten)
>Command 2 (Datensicherung anwerfen)
>Command 3 (Daemon anschalten)
>
>Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
>recht lange dauert, beendet ist. Und genau das ist mein Problem.
bleibt, bis das Backup abgeschlossen ist.
>Die PID von Command 2 hilft mir zur Zeit auch nicht weiter, denn
>a) sie ist auch nach abgeschlossener Datensicherung noch existent
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Holger Marzen
May 9, 2013, 9:14:33 AM5/9/13
to
* On Thu, 09 May 2013 14:51:57 +0200, Paul-Wilhelm Hermsen wrote:
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
>
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
>
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
> b) weil die Datensicherung beendet ist, Command 3 ausgeführt wird.
Alles in ein Script und darin alle Kommandos im Vordergrund durchführen.
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
>
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
>
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
> b) weil die Datensicherung beendet ist, Command 3 ausgeführt wird.
Helmut Hullen
May 9, 2013, 9:31:00 AM5/9/13
to
Hallo, Paul-Wilhelm,
Du meintest am 09.05.13:
> Ich habe ein Skript folgender Art
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche
> z.T. recht lange dauert, beendet ist. Und genau das ist mein Problem.
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
> b) weil die Datensicherung beendet ist, Command 3 ausgef�hrt wird.
Am ehesten w�rde ich
Command2 && Command3
benutzen.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Du meintest am 09.05.13:
> Ich habe ein Skript folgender Art
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche
> z.T. recht lange dauert, beendet ist. Und genau das ist mein Problem.
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
Am ehesten w�rde ich
Command2 && Command3
benutzen.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Paul-Wilhelm Hermsen
May 9, 2013, 9:52:00 AM5/9/13
to
Am 09.05.13 15:10, schrieb Marc Haber:
> Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
> bleibt, bis das Backup abgeschlossen ist.
PW="$(osascript -e 'yes '' | tell application "System Events" to display
dialog "Password:" default answer "PASSWORD" with hidden answer' -e
'text returned of result' 2>/dev/null)"
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
echo "$PW" | sudo -S fg
[%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
OK?
Hier ist der Skriptinhalt.
Der 1. Block erfragt ein Passwort, das in eine Variable gepackt wird.
Der 2. Block stoppt den Daemon.
Der 3. Block schmeißt die Datensicherung an.
Der 4. Block soll nur ausgeführt werden, wenn sie beendet ist.
Wo und wie bringe ich da mein fg unter?
>> Die PID vom 3. Block hilft mir zur Zeit auch nicht weiter, denn
> Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
> bleibt, bis das Backup abgeschlossen ist.
dialog "Password:" default answer "PASSWORD" with hidden answer' -e
'text returned of result' 2>/dev/null)"
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
echo "$PW" | sudo -S fg
[%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
OK?
Hier ist der Skriptinhalt.
Der 1. Block erfragt ein Passwort, das in eine Variable gepackt wird.
Der 2. Block stoppt den Daemon.
Der 3. Block schmeißt die Datensicherung an.
Der 4. Block soll nur ausgeführt werden, wenn sie beendet ist.
Wo und wie bringe ich da mein fg unter?
>> Die PID vom 3. Block hilft mir zur Zeit auch nicht weiter, denn
>> a) sie ist auch nach abgeschlossener Datensicherung noch existent
>
> Warum?
Wenn ich das mal wüßte!
>
> Warum?
Paul-Wilhelm Hermsen
May 9, 2013, 9:58:44 AM5/9/13
to
Am 09.05.13 15:14, schrieb Holger Marzen:
Ich weiß nicht einmal, wie ich ein fg für einen Befehl dort unterbringe,
geschweige denn für alle?
> Alles in ein Script und darin alle Kommandos im Vordergrund durchführen.
Beim Marc kannst Du mein Skript mal nachlesen.
Ich weiß nicht einmal, wie ich ein fg für einen Befehl dort unterbringe,
geschweige denn für alle?
Paul-Wilhelm Hermsen
May 9, 2013, 10:05:53 AM5/9/13
to
Am 09.05.13 15:31, schrieb Helmut Hullen:
> Hallo, Paul-Wilhelm,
daran habe ich auch schon gedacht. So einfach ist das aber wohl nicht,
denn Command2 wird ja durchaus beendet, derweil sein Prozess aber noch
andauert. Mir kommt es darauf an, dass der Prozess, der durch Command2
gestartet wird, beendet sein soll, bevor Command3 gestartet wird.
> Hallo, Paul-Wilhelm,
> Am ehesten w�rde ich
>
> Command2 && Command3
>
> benutzen.
Hallo Helmut,
>
> Command2 && Command3
>
> benutzen.
daran habe ich auch schon gedacht. So einfach ist das aber wohl nicht,
denn Command2 wird ja durchaus beendet, derweil sein Prozess aber noch
andauert. Mir kommt es darauf an, dass der Prozess, der durch Command2
gestartet wird, beendet sein soll, bevor Command3 gestartet wird.
Holger Marzen
May 9, 2013, 10:20:36 AM5/9/13
to
* On Thu, 09 May 2013 15:52:00 +0200, Paul-Wilhelm Hermsen wrote:
> Am 09.05.13 15:10, schrieb Marc Haber:
>
>> Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
>> bleibt, bis das Backup abgeschlossen ist.
>
> PW="$(osascript -e 'yes '' | tell application "System Events" to display
> dialog "Password:" default answer "PASSWORD" with hidden answer' -e
> 'text returned of result' 2>/dev/null)"
>
> echo "$PW" | sudo -S launchctl unload
> /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
>
> echo "$PW" | sudo -S fg
> [%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
>
> echo "$PW" | sudo -S launchctl load
> /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
>
> OK?
>
> Hier ist der Skriptinhalt.
> Der 1. Block erfragt ein Passwort, das in eine Variable gepackt wird.
> Der 2. Block stoppt den Daemon.
> Der 3. Block schmeißt die Datensicherung an.
> Der 4. Block soll nur ausgeführt werden, wenn sie beendet ist.
>
> Wo und wie bringe ich da mein fg unter?
Ich habe keine Ahnung, was Apple so verbastelt hat, und welche Shell
> Am 09.05.13 15:10, schrieb Marc Haber:
>
>> Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
>> bleibt, bis das Backup abgeschlossen ist.
>
> PW="$(osascript -e 'yes '' | tell application "System Events" to display
> dialog "Password:" default answer "PASSWORD" with hidden answer' -e
> 'text returned of result' 2>/dev/null)"
>
> echo "$PW" | sudo -S launchctl unload
> /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
>
> echo "$PW" | sudo -S fg
> [%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
>
> echo "$PW" | sudo -S launchctl load
> /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
>
> OK?
>
> Hier ist der Skriptinhalt.
> Der 1. Block erfragt ein Passwort, das in eine Variable gepackt wird.
> Der 2. Block stoppt den Daemon.
> Der 3. Block schmeißt die Datensicherung an.
> Der 4. Block soll nur ausgeführt werden, wenn sie beendet ist.
>
> Wo und wie bringe ich da mein fg unter?
läuft. Aber vielleicht hilft ein "wait" zwischen 3. und 4. Block. Wenn
dieser ominöse backupd-helper sich allerdings dämonisiert und nicht nur
hintergrundisiert, dann würde ich eine Anfrage an Apple stellen, wie man
das Ende einer Datensicherung erkennen kann. Der Hersteller muss es
schließlich wissen.
Paul-Wilhelm Hermsen
May 9, 2013, 10:25:01 AM5/9/13
to
Am 09.05.13 15:52, schrieb Paul-Wilhelm Hermsen:
Richtig ist folgender:
echo "$PW" | sudo -S
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
Dieser Block sollte einen Prozess hervorrufen, der im Vordergrund
abläuft, damit, wie Du empfohlen hast, die hier gestartete
Datensicherung beendet ist, bevor der nächste Block aufgerufen wird.
In diesem Block wird das zuvor abgefragte sudo-Passwort in die Pipe
geschickt, und sudo startet dann erfolgreich die Datensicherung.
Wie bringe ich jetzt da fg unter?
> echo "$PW" | sudo -S fg
> [%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
Der Block ist übrigens falsch.
> [%/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper]
Richtig ist folgender:
echo "$PW" | sudo -S
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
Dieser Block sollte einen Prozess hervorrufen, der im Vordergrund
abläuft, damit, wie Du empfohlen hast, die hier gestartete
Datensicherung beendet ist, bevor der nächste Block aufgerufen wird.
In diesem Block wird das zuvor abgefragte sudo-Passwort in die Pipe
geschickt, und sudo startet dann erfolgreich die Datensicherung.
Wie bringe ich jetzt da fg unter?
Paul-Wilhelm Hermsen
May 9, 2013, 10:36:52 AM5/9/13
to
Am 09.05.13 16:20, schrieb Holger Marzen:
> Wenn dieser ominöse backupd-helper sich allerdings dämonisiert...
So ist es wohl, und deshalb, vermute ich mal, spielt es keine Rolle, ob
die dadurch gestartete Datensicherung beendet ist, oder nicht; der Dämon
läuft weiter.
Den backupd abzuwürgen, ist kein Problem. Mir geht es aber um die
Datensicherung, die ich natürlich auch abwürge, wenn ich backupd abwürge.
Und - ich habe keine Ahnung von Skriptsyntax, was noch erschwerend hinzu
kommt.
Das kann man aus Linuxsicht durchaus als von Apple "verbandelt" bezeichnen.
> Wenn dieser ominöse backupd-helper sich allerdings dämonisiert...
So ist es wohl, und deshalb, vermute ich mal, spielt es keine Rolle, ob
die dadurch gestartete Datensicherung beendet ist, oder nicht; der Dämon
läuft weiter.
Den backupd abzuwürgen, ist kein Problem. Mir geht es aber um die
Datensicherung, die ich natürlich auch abwürge, wenn ich backupd abwürge.
Und - ich habe keine Ahnung von Skriptsyntax, was noch erschwerend hinzu
kommt.
Das kann man aus Linuxsicht durchaus als von Apple "verbandelt" bezeichnen.
Helmut Hullen
May 9, 2013, 10:43:00 AM5/9/13
to
Hallo, Paul-Wilhelm,
Du meintest am 09.05.13:
Du meintest am 09.05.13:
>> Am ehesten w�rde ich
>>
>> Command2 && Command3
>>
>> benutzen.
>>
>> Command2 && Command3
>>
>> benutzen.
> daran habe ich auch schon gedacht. So einfach ist das aber wohl
> nicht, denn Command2 wird ja durchaus beendet, derweil sein Prozess
> aber noch andauert. Mir kommt es darauf an, dass der Prozess, der
> durch Command2 gestartet wird, beendet sein soll, bevor Command3
> gestartet wird.
Ok - "Command2" ist also nur ein Starter. F�r welches Programm?
> nicht, denn Command2 wird ja durchaus beendet, derweil sein Prozess
> aber noch andauert. Mir kommt es darauf an, dass der Prozess, der
> durch Command2 gestartet wird, beendet sein soll, bevor Command3
> gestartet wird.
Wird dieses Programm nur und ausschliesslich von "Command2" gestartet?
Die schnelle und schmutzige Methode: Prozess-ID mit Hilfe von (z.B.)
pgrep -l -x <Programmname>
pr�fen; solange warten, bis pgrep nichts mehr anzeigt. Das kann aber
(bei irgendwelchen Fehlern) ewig dauern.
K�nnte es sein, dass das Programm, das von "Command2" gestartet wird,
sowieso irgendwo vermerkt, dass es l�uft? �blich ist, dass es sein PID
z.B. nach "/var/run/<pid-Datei>" oder nach "/var/pid/<pid-Datei>"
schreibt.
Paul-Wilhelm Hermsen
May 9, 2013, 11:19:35 AM5/9/13
to
Am 09.05.13 15:10, schrieb Marc Haber:
>> Die PID von Command 2 hilft mir zur Zeit auch nicht weiter, denn
>> >a) sie ist auch nach abgeschlossener Datensicherung noch existent
> Warum?
OK - ich komme meinem Ziel näher.
>> >a) sie ist auch nach abgeschlossener Datensicherung noch existent
> Warum?
Jetzt habe ich durch einen anderen Befehl dafür gesorgt, dass der
Backupprozess auch aus der Prozessliste verschwindet, wenn die
Datensicherung beendet ist.
D.h. ich kann jetzt die Prozesspid dazu nutzen, dass es weiter geht,
wenn sie nicht mehr da ist.
Ausgelesen wird die pid im Skript mittels
ps aux | grep backupd | grep -v grep | awk '{print $2}'
Wie nutze ich jetzt diese pid um zu erreichen, dass abgewartet wird,
solange sie da ist und weiter gemacht wird, sobald sie nicht mehr da ist.
Das wäre ja vermutlich die hier erforderliche Lösung.
Paul-Wilhelm Hermsen
May 9, 2013, 11:31:26 AM5/9/13
to
Am 09.05.13 16:43, schrieb Helmut Hullen:
> Hallo, Paul-Wilhelm,
> Ok - "Command2" ist also nur ein Starter. F�r welches Programm?
Datensicherung via Time Machine (Apple)
> Wird dieses Programm nur und ausschliesslich von "Command2" gestartet?
Man kann es auf zweilerlei Weise starten und genau daran habe ich jetzt
herum operiert und erst einmal daf�r gesorgt, dass eine ordentliche pid
erzeugt wird, die am Ende des Prozesses wieder verschwindet, was beim
ersten Versuch nicht der Fall war.
> Die schnelle und schmutzige Methode: Prozess-ID mit Hilfe von (z.B.)
>
> pgrep -l -x <Programmname>
>
> pr�fen; solange warten, bis pgrep nichts mehr anzeigt. Das kann aber
> (bei irgendwelchen Fehlern) ewig dauern.
H�rt sich gut an. Wie bringe ich das jetzt einer wie auch immer
gearteten Warteanweisung bei?
> K�nnte es sein, dass das Programm, das von "Command2" gestartet wird,
> sowieso irgendwo vermerkt, dass es l�uft? �blich ist, dass es sein PID
> z.B. nach "/var/run/<pid-Datei>" oder nach "/var/pid/<pid-Datei>"
> schreibt.
Die pid ist jedenfalls ein Ansatz. Ausgelesen wird sie in meinem Skript mit
ps aux | grep backupd | grep -v grep | awk '{print $2}'
Jetzt fehlt mir, wie gesagt, f�r das Skript nur noch die Anweisung, dass
erst dann weiter gemacht wird, wenn die pid nicht mehr da ist.
LG
PW
> Hallo, Paul-Wilhelm,
> Ok - "Command2" ist also nur ein Starter. F�r welches Programm?
> Wird dieses Programm nur und ausschliesslich von "Command2" gestartet?
herum operiert und erst einmal daf�r gesorgt, dass eine ordentliche pid
erzeugt wird, die am Ende des Prozesses wieder verschwindet, was beim
ersten Versuch nicht der Fall war.
> Die schnelle und schmutzige Methode: Prozess-ID mit Hilfe von (z.B.)
>
> pgrep -l -x <Programmname>
>
> pr�fen; solange warten, bis pgrep nichts mehr anzeigt. Das kann aber
> (bei irgendwelchen Fehlern) ewig dauern.
gearteten Warteanweisung bei?
> K�nnte es sein, dass das Programm, das von "Command2" gestartet wird,
> sowieso irgendwo vermerkt, dass es l�uft? �blich ist, dass es sein PID
> z.B. nach "/var/run/<pid-Datei>" oder nach "/var/pid/<pid-Datei>"
> schreibt.
ps aux | grep backupd | grep -v grep | awk '{print $2}'
erst dann weiter gemacht wird, wenn die pid nicht mehr da ist.
LG
PW
Helmut Hullen
May 9, 2013, 11:36:00 AM5/9/13
to
Hallo, Paul-Wilhelm,
Du meintest am 09.05.13:
Du meintest am 09.05.13:
> D.h. ich kann jetzt die Prozesspid dazu nutzen, dass es weiter geht,
> wenn sie nicht mehr da ist.
> Ausgelesen wird die pid im Skript mittels
> ps aux | grep backupd | grep -v grep | awk '{print $2}'
Einfacher:
> wenn sie nicht mehr da ist.
> Ausgelesen wird die pid im Skript mittels
> ps aux | grep backupd | grep -v grep | awk '{print $2}'
pgrep -l -x backupd > /dev/null
Wenn der Prozess noch l�uft, dann ist der R�ckgabewert "true"/"ok".
> Wie nutze ich jetzt diese pid um zu erreichen, dass abgewartet wird,
> solange sie da ist und weiter gemacht wird, sobald sie nicht mehr da
while pgrep -l -x backupd > /dev/null
do
sleep 60
done
Was soll passieren, wenn der backup-Prozess sich aufh�ngt?
Lars Behrens
May 9, 2013, 11:41:47 AM5/9/13
to
Am 09.05.2013 17:31, schrieb Paul-Wilhelm Hermsen:
> Jetzt fehlt mir, wie gesagt, f�r das Skript nur noch die Anweisung, dass
> erst dann weiter gemacht wird, wenn die pid nicht mehr da ist.
z.B.
> Jetzt fehlt mir, wie gesagt, f�r das Skript nur noch die Anweisung, dass
> erst dann weiter gemacht wird, wenn die pid nicht mehr da ist.
while pgrep [PID]; do sleep [Zeit in Sekunden]; done
Cheerz,
Lars
Paul-Wilhelm Hermsen
May 9, 2013, 12:19:28 PM5/9/13
to
Am 09.05.13 17:36, schrieb Helmut Hullen:
> Einfacher:
>
> pgrep -l -x backupd > /dev/null
>
> Wenn der Prozess noch l�uft, dann ist der R�ckgabewert "true"/"ok".
OK!
>> > Wie nutze ich jetzt diese pid um zu erreichen, dass abgewartet wird,
>> > solange sie da ist und weiter gemacht wird, sobald sie nicht mehr da
>> > ist. Das w�re ja vermutlich die hier erforderliche L�sung.
> while pgrep -l -x backupd > /dev/null
> do
> sleep 60
> done
Wunderbar!
Und ich dachte, sleep 60 z.B. w�rde bedeuten, dass in jedem Fall nach 60
Sekunden weiter gemacht wird. Demzufolge bedeutet es aber, dass nach 60
Sekunden erneut der R�ckgabewert �berpr�ft wird und bei true weitere 60
Sekunden abgewartet werden?
> Was soll passieren, wenn der backup-Prozess sich aufh�ngt?
Beim Mac hat sich bisher noch nix aufgeh�ngt! ;-)
Nein - Scherz beiseite!
Diese �berlegung rundet nat�rlich das Skript ab.
H�ngenden Prozess abw�rgen! Aber wie stelle ich fest, dass der Prozess
tats�chlich h�ngt, und wie w�rge ich ihn dann im Skript ab?
Auf jeden Fall bis hierhin schon mal ein gro�es DANKE!
> Einfacher:
>
> pgrep -l -x backupd > /dev/null
>
> Wenn der Prozess noch l�uft, dann ist der R�ckgabewert "true"/"ok".
>> > Wie nutze ich jetzt diese pid um zu erreichen, dass abgewartet wird,
>> > solange sie da ist und weiter gemacht wird, sobald sie nicht mehr da
>> > ist. Das w�re ja vermutlich die hier erforderliche L�sung.
> while pgrep -l -x backupd > /dev/null
> do
> sleep 60
> done
Und ich dachte, sleep 60 z.B. w�rde bedeuten, dass in jedem Fall nach 60
Sekunden weiter gemacht wird. Demzufolge bedeutet es aber, dass nach 60
Sekunden erneut der R�ckgabewert �berpr�ft wird und bei true weitere 60
Sekunden abgewartet werden?
> Was soll passieren, wenn der backup-Prozess sich aufh�ngt?
Nein - Scherz beiseite!
Diese �berlegung rundet nat�rlich das Skript ab.
H�ngenden Prozess abw�rgen! Aber wie stelle ich fest, dass der Prozess
tats�chlich h�ngt, und wie w�rge ich ihn dann im Skript ab?
Auf jeden Fall bis hierhin schon mal ein gro�es DANKE!
Thomas 'PointedEars' Lahn
May 9, 2013, 12:44:13 PM5/9/13
to
Paul-Wilhelm Hermsen wrote:
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
> […]
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
> Alles klar, oder habe ich mich zu verworren ausgedrückt?
Nicht unbedingt. Aber Du hast sinnlos (erste Zeile) und
off-topic (hier statt in de.comp.os.unix.shell) gepostet.
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Paul-Wilhelm Hermsen
May 9, 2013, 12:57:33 PM5/9/13
to
Am 09.05.13 18:44, schrieb Thomas 'PointedEars' Lahn:
Aber
a) in der von Dir genannten NG herrscht diesbezüglich absolute
Funkstille und
b) Du bist mit Deinen diesbezüglichen Hinweisen eigentlich auch immer ot
c) Diejenigen, welche die Lösung kennen, sitzen auch nicht immer in den
richtigen Gruppen!
Diese für Dich typischen Maßregelungen entsprechen nicht weniger den
Usenetregeln, als vereinzelte OTs und sind zudem noch äußerst langweilig.
> Paul-Wilhelm Hermsen wrote:
> Nicht unbedingt. Aber Du hast sinnlos (erste Zeile) und
> off-topic (hier statt in de.comp.os.unix.shell) gepostet.
Hast mal wieder Recht!
> Nicht unbedingt. Aber Du hast sinnlos (erste Zeile) und
> off-topic (hier statt in de.comp.os.unix.shell) gepostet.
Aber
a) in der von Dir genannten NG herrscht diesbezüglich absolute
Funkstille und
b) Du bist mit Deinen diesbezüglichen Hinweisen eigentlich auch immer ot
c) Diejenigen, welche die Lösung kennen, sitzen auch nicht immer in den
richtigen Gruppen!
Diese für Dich typischen Maßregelungen entsprechen nicht weniger den
Usenetregeln, als vereinzelte OTs und sind zudem noch äußerst langweilig.
Thomas 'PointedEars' Lahn
May 9, 2013, 1:01:56 PM5/9/13
to
Paul-Wilhelm Hermsen wrote:
> Am 09.05.13 18:44, schrieb Thomas 'PointedEars' Lahn:
> Am 09.05.13 18:44, schrieb Thomas 'PointedEars' Lahn:
>> Nicht unbedingt. Aber Du hast sinnlos (erste Zeile) und
>> off-topic (hier statt in de.comp.os.unix.shell) gepostet.
>
> Hast mal wieder Recht!
>
> Aber
> a) in der von Dir genannten NG herrscht diesbezüglich absolute
> Funkstille und
Natürlich, wenn dort niemand fragt, passiert dort auch nichts. Die Leute
>> off-topic (hier statt in de.comp.os.unix.shell) gepostet.
>
> Hast mal wieder Recht!
>
> Aber
> a) in der von Dir genannten NG herrscht diesbezüglich absolute
> Funkstille und
die Ahnung haben, brauchen meist nicht zu fragen. Du velwechserst Ursache
und Wirkung.
> b) Du bist mit Deinen diesbezüglichen Hinweisen eigentlich auch immer ot
> c) Diejenigen, welche die Lösung kennen, sitzen auch nicht immer in den
> richtigen Gruppen!
nicht bzw. miss-verstanden.
> Diese für Dich typischen Maßregelungen
Probleme wie Du haben, eher geholfen wird, Du Flachpfeife.
> entsprechen nicht weniger den Usenetregeln, als vereinzelte OTs und sind
> zudem noch äußerst langweilig.
Paul-Wilhelm Hermsen
May 9, 2013, 1:07:09 PM5/9/13
to
Am 09.05.13 19:01, schrieb Thomas 'PointedEars' Lahn:
> Natürlich, wenn dort niemand fragt, passiert dort auch nichts. Die Leute
> die Ahnung haben, brauchen meist nicht zu fragen. Du velwechserst Ursache
> und Wirkung.
Wie schrecklich!
Schau mal in der NG nach, bevor Du mir unterstellst, ich hätte dort
nicht gepostet, Du Spitzohr!
> Natürlich, wenn dort niemand fragt, passiert dort auch nichts. Die Leute
> die Ahnung haben, brauchen meist nicht zu fragen. Du velwechserst Ursache
> und Wirkung.
> Das war ein freundlicher Hinweis, damit Dir und anderen, die ähnliche
> Probleme wie Du haben, eher geholfen wird, Du Flachpfeife.
> Geh sterben.
> Probleme wie Du haben, eher geholfen wird, Du Flachpfeife.
Wie schrecklich!
Schau mal in der NG nach, bevor Du mir unterstellst, ich hätte dort
nicht gepostet, Du Spitzohr!
Helmut Hullen
May 9, 2013, 12:44:00 PM5/9/13
to
Hallo, Paul-Wilhelm,
Du meintest am 09.05.13:
[...]
Du meintest am 09.05.13:
>>>> Wie nutze ich jetzt diese pid um zu erreichen, dass abgewartet
>>>> wird, solange sie da ist und weiter gemacht wird, sobald sie nicht
>>>> mehr da ist. Das w�re ja vermutlich die hier erforderliche L�sung.
>> while pgrep -l -x backupd > /dev/null
>> do
>> sleep 60
>> done
> Wunderbar!
> Und ich dachte, sleep 60 z.B. w�rde bedeuten, dass in jedem Fall nach
> 60 Sekunden weiter gemacht wird. Demzufolge bedeutet es aber, dass
> nach 60 Sekunden erneut der R�ckgabewert �berpr�ft wird und bei true
> weitere 60 Sekunden abgewartet werden?
>> Was soll passieren, wenn der backup-Prozess sich aufh�ngt?
> Beim Mac hat sich bisher noch nix aufgeh�ngt! ;-)
> Nein - Scherz beiseite!
> Diese �berlegung rundet nat�rlich das Skript ab.
> H�ngenden Prozess abw�rgen! Aber wie stelle ich fest, dass der
> Prozess tats�chlich h�ngt, und wie w�rge ich ihn dann im Skript ab?
dauern k�nnte.
Abw�rgen:
(als "root" - ich mag dieses "sudo"-Geraffel nicht)
killall backupd
killall backupd
pgrep -l -x backupd
w�re die Brechstangenl�sung zu Fuss.
"killall" erlaubt bei Linux (und hier ist ja eine Linux-Gruppe), den
Namen der Anwendung anzugeben. Und wenn der Befehl noch mal aufgerufen
wird, der Prozess aber bereits brav gestoppt ist (oder sowieso nicht
l�uft), dann gibt es eine saubere Fehlermeldung. Die "pgrep"-Zeile ist
nur noch f�r die Neurotiker, die besonders misstrauisch sind.
Folgeproblem: was ist mit dem Backup anzufangen, das vorzeitig abgew�rgt
wurde?
Helmut Hullen
May 9, 2013, 1:17:00 PM5/9/13
to
Hallo, Paul-Wilhelm,
Du meintest am 09.05.13:
Du meintest am 09.05.13:
> Am 09.05.13 19:01, schrieb Thomas 'PointedEars' Lahn:
[...]
>> Geh sterben.
> Wie schrecklich!
Thomas glaubt nun mal felsenfest daran, hier den Hausmeister machen zu
m�ssen.
Thomas 'PointedEars' Lahn
May 9, 2013, 1:30:23 PM5/9/13
to
[X-Post de.comp.os.unix.linux.misc, de.soc.usenet; F'up2 de.soc.usenet]
Paul-Wilhelm Hermsen wrote in de.comp.os.unix.linux.misc:
> Am 09.05.13 19:01, schrieb Thomas 'PointedEars' Lahn:
>> Natürlich, wenn dort niemand fragt, passiert dort auch nichts. Die Leute
>> die Ahnung haben, brauchen meist nicht zu fragen. Du velwechserst
>> Ursache und Wirkung.
>
>> Das war ein freundlicher Hinweis, damit Dir und anderen, die ähnliche
>> Probleme wie Du haben, eher geholfen wird, Du Flachpfeife.
>
>> Geh sterben.
<http://learn.to/quote>
> Wie schrecklich!
Ach was, das tut gar nicht weh. Jedenfalls mir nicht.
> Schau mal in der NG nach, bevor Du mir unterstellst, ich hätte dort
> nicht gepostet, Du Spitzohr!
Niemand hat Dir irgendwas unterstellt. Anscheinend hast Du aber neben der
Themenorientierung des Usenets auch seine sonstige Funktionsweise nicht so
recht verstanden. Denn:
1. Du postest *off-topic* (Linux != Mac OS X) hier *heute* um 14.51 Uhr.
2. Du postest *dasselbe* in dcous *heute* 14.56 Uhr. (Und wer weiss wo
sonst noch zur gleichen Zeit.)
3. Du *beschwerst* Dich *heute* um 18.57 Uhr hier *ernsthaft*, dass noch
niemand in dcous geantwortet hat. Nach einem Multiposting, und an einem
Feiertag, bei dem man gut „die Brücke machen“ kann.
Merkst Du einklich [1] noch was? [2]
[1] <http://einklich.net/usenet/bremslicht.txt>
<http://einklich.net/usenet/usenet1.htm>
[2] <http://www.tty1.net/smart-questions_de.html>
--
PointedEars, fuppend
Paul-Wilhelm Hermsen wrote in de.comp.os.unix.linux.misc:
> Am 09.05.13 19:01, schrieb Thomas 'PointedEars' Lahn:
>> Natürlich, wenn dort niemand fragt, passiert dort auch nichts. Die Leute
>> die Ahnung haben, brauchen meist nicht zu fragen. Du velwechserst
>> Ursache und Wirkung.
>
>> Das war ein freundlicher Hinweis, damit Dir und anderen, die ähnliche
>> Probleme wie Du haben, eher geholfen wird, Du Flachpfeife.
>
>> Geh sterben.
> Wie schrecklich!
Ach was, das tut gar nicht weh. Jedenfalls mir nicht.
> Schau mal in der NG nach, bevor Du mir unterstellst, ich hätte dort
> nicht gepostet, Du Spitzohr!
Themenorientierung des Usenets auch seine sonstige Funktionsweise nicht so
recht verstanden. Denn:
1. Du postest *off-topic* (Linux != Mac OS X) hier *heute* um 14.51 Uhr.
2. Du postest *dasselbe* in dcous *heute* 14.56 Uhr. (Und wer weiss wo
sonst noch zur gleichen Zeit.)
3. Du *beschwerst* Dich *heute* um 18.57 Uhr hier *ernsthaft*, dass noch
niemand in dcous geantwortet hat. Nach einem Multiposting, und an einem
Feiertag, bei dem man gut „die Brücke machen“ kann.
Merkst Du einklich [1] noch was? [2]
[1] <http://einklich.net/usenet/bremslicht.txt>
<http://einklich.net/usenet/usenet1.htm>
[2] <http://www.tty1.net/smart-questions_de.html>
--
PointedEars, fuppend
Paul-Wilhelm Hermsen
May 9, 2013, 1:35:32 PM5/9/13
to
Am 09.05.13 18:44, schrieb Helmut Hullen:
�blicher Weise nichts!
Unter OS X haben wir es in case of Time Machine aber durchaus mit einem
sehr intelligenten Datensicherungsmodell zu tun, dass ich um nichts mehr
missen m�chte. Das kann man ruhig abw�rgen. Beim n�chsten Mal wird an
der Stelle wieder angesetzt, an welcher das Backup zuletzt erfolgreich war.
Und w�rde der Spotlight-Suchd�mon nicht dauernd w�hrend der Backups
seine Schn�ffelnase zwecks Indizierung in wirklich aber auch Alles
reinstecken, sogar in das Backup, h�tte ich mir dieses Skript gar nicht
ausdenken m�ssen. Die erste komplette Datensicherung meiner etwa 600 GB
auf Time Capsule sollte so um die 72 Tage dauern, wegen Spotlight.
Offenbar ein immer mal wieder kehrender Bug unter OS X, wenn Time
Machine und Backup zusammen laufen.
Also musste ein Skript her, um f�r die Dauer der Datensicherung
Spotlight ab- und danach wieder anzuschalten.
Lass mal gut sein.
Ich danke Dir sehr!
LG
PW
> Folgeproblem: was ist mit dem Backup anzufangen, das vorzeitig abgew�rgt
> wurde?
LOL
> wurde?
�blicher Weise nichts!
Unter OS X haben wir es in case of Time Machine aber durchaus mit einem
sehr intelligenten Datensicherungsmodell zu tun, dass ich um nichts mehr
missen m�chte. Das kann man ruhig abw�rgen. Beim n�chsten Mal wird an
der Stelle wieder angesetzt, an welcher das Backup zuletzt erfolgreich war.
Und w�rde der Spotlight-Suchd�mon nicht dauernd w�hrend der Backups
seine Schn�ffelnase zwecks Indizierung in wirklich aber auch Alles
reinstecken, sogar in das Backup, h�tte ich mir dieses Skript gar nicht
ausdenken m�ssen. Die erste komplette Datensicherung meiner etwa 600 GB
auf Time Capsule sollte so um die 72 Tage dauern, wegen Spotlight.
Offenbar ein immer mal wieder kehrender Bug unter OS X, wenn Time
Machine und Backup zusammen laufen.
Also musste ein Skript her, um f�r die Dauer der Datensicherung
Spotlight ab- und danach wieder anzuschalten.
Lass mal gut sein.
Ich danke Dir sehr!
LG
PW
Paul-Wilhelm Hermsen
May 9, 2013, 1:37:04 PM5/9/13
to
Am 09.05.13 19:35, schrieb Paul-Wilhelm Hermsen:
> Offenbar ein immer mal wieder kehrender Bug unter OS X, wenn Time
> Machine und Backup zusammen laufen.
Sollte hei�en, Time Machine und Spotlight.
> Offenbar ein immer mal wieder kehrender Bug unter OS X, wenn Time
> Machine und Backup zusammen laufen.
Sieghard Schicktanz
May 9, 2013, 3:46:25 PM5/9/13
to
Hallo Lars,
Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
> z.B.
> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
oder, bei Verwendung der bash zumindest (sollten andere shells aber auch
k�nnen, da POSIX), "wait".
Aus "man bash":
wait [n ...]
Wait for each specified process and return its termination
status. Each n may be a process ID or a job specification;
if a job spec is given, all processes in that job's
pipeline are waited for. If n is not given, all currently
active child pro- cesses are waited for, and the return
status is zero. If n specifies a non-existent process or job,
the return status is 127. Otherwise, the return status
is the exit status of the last process or job waited for.
Damit sollte ein "wait $PID" mit der PID des Backup-Prozesses in PID
reichen. Ohne Schleife, und ohne die dadurch entstehende zus�tzliche
Verz�gerng von bis zu "[Zeit in Sekunden]".
--
(Weitergabe von Adressdaten, Telefonnummern u.�. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder �hnlichem)
-----------------------------------------------------------
Mit freundlichen Gr��en, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
> z.B.
> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
k�nnen, da POSIX), "wait".
Aus "man bash":
wait [n ...]
Wait for each specified process and return its termination
status. Each n may be a process ID or a job specification;
if a job spec is given, all processes in that job's
pipeline are waited for. If n is not given, all currently
active child pro- cesses are waited for, and the return
status is zero. If n specifies a non-existent process or job,
the return status is 127. Otherwise, the return status
is the exit status of the last process or job waited for.
Damit sollte ein "wait $PID" mit der PID des Backup-Prozesses in PID
reichen. Ohne Schleife, und ohne die dadurch entstehende zus�tzliche
Verz�gerng von bis zu "[Zeit in Sekunden]".
--
(Weitergabe von Adressdaten, Telefonnummern u.�. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder �hnlichem)
-----------------------------------------------------------
Mit freundlichen Gr��en, S. Schicktanz
-----------------------------------------------------------
Marc Haber
May 9, 2013, 4:22:27 PM5/9/13
to
nicht verhindern.
Wo hast Du eigentlich geschrieben, dass es um MacOS und nicht um Linux
geht? Und warum fragst Du in einer Linuxgruppe?
Paul-Wilhelm Hermsen
May 9, 2013, 4:32:18 PM5/9/13
to
Am 09.05.13 21:46, schrieb Sieghard Schicktanz:
Ich werde als Skriptnovice auch durch Eure L�sungvorschl�ge lernen. Es
f�hren ja mehrere Wege zum Ziel. Am elegantesten ist immer die k�rzeste
Methode, sowohl im Code als auch in der Zeit, welche er verspeist.
Mir geht es bei dieser und �hnlich gelagerten Aufgaben allerdings aus
nachvollziehbaren Gr�nden um das generelle Verst�ndnis. Denn da bin ich
noch nicht einmal raus aus dem Ei, sondern klopfe gerade erst einmal von
innen gegen die Schale.
:-)
> Hallo Lars,
>
> Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
>
>> z.B.
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
> oder, bei Verwendung der bash zumindest (sollten andere shells aber auch
> k�nnen, da POSIX), "wait".
> Aus "man bash":
>
> wait [n ...]
> Wait for each specified process and return its termination
> status. Each n may be a process ID or a job specification;
> if a job spec is given, all processes in that job's
> pipeline are waited for. If n is not given, all currently
> active child pro- cesses are waited for, and the return
> status is zero. If n specifies a non-existent process or job,
> the return status is 127. Otherwise, the return status
> is the exit status of the last process or job waited for.
>
> Damit sollte ein "wait $PID" mit der PID des Backup-Prozesses in PID
> reichen. Ohne Schleife, und ohne die dadurch entstehende zus�tzliche
> Verz�gerng von bis zu "[Zeit in Sekunden]".
>
Vielen Dank an Euch Beide!
>
> Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
>
>> z.B.
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
> oder, bei Verwendung der bash zumindest (sollten andere shells aber auch
> k�nnen, da POSIX), "wait".
> Aus "man bash":
>
> wait [n ...]
> Wait for each specified process and return its termination
> status. Each n may be a process ID or a job specification;
> if a job spec is given, all processes in that job's
> pipeline are waited for. If n is not given, all currently
> active child pro- cesses are waited for, and the return
> status is zero. If n specifies a non-existent process or job,
> the return status is 127. Otherwise, the return status
> is the exit status of the last process or job waited for.
>
> Damit sollte ein "wait $PID" mit der PID des Backup-Prozesses in PID
> reichen. Ohne Schleife, und ohne die dadurch entstehende zus�tzliche
> Verz�gerng von bis zu "[Zeit in Sekunden]".
>
Ich werde als Skriptnovice auch durch Eure L�sungvorschl�ge lernen. Es
f�hren ja mehrere Wege zum Ziel. Am elegantesten ist immer die k�rzeste
Methode, sowohl im Code als auch in der Zeit, welche er verspeist.
Mir geht es bei dieser und �hnlich gelagerten Aufgaben allerdings aus
nachvollziehbaren Gr�nden um das generelle Verst�ndnis. Denn da bin ich
noch nicht einmal raus aus dem Ei, sondern klopfe gerade erst einmal von
innen gegen die Schale.
:-)
Paul-Wilhelm Hermsen
May 9, 2013, 4:39:37 PM5/9/13
to
Am 09.05.13 22:22, schrieb Marc Haber:
> Wo hast Du eigentlich geschrieben, dass es um MacOS und nicht um Linux
> geht?
Nirgendwo - spielt eigentlich, abgesehen von gewissen Sonderheiten,
keine Rolle.
> Und warum fragst Du in einer Linuxgruppe?
Soll ich Dir das jetzt wirklich ernsthaft beantworten, ohne mich bei den
OS Xlern ins Abseits zu manövrieren?
;-)
Besser nicht.
Hier ist meine Frage ja hervorragend beantwortet worden.
LG
PW
> Wo hast Du eigentlich geschrieben, dass es um MacOS und nicht um Linux
> geht?
keine Rolle.
> Und warum fragst Du in einer Linuxgruppe?
OS Xlern ins Abseits zu manövrieren?
;-)
Besser nicht.
Hier ist meine Frage ja hervorragend beantwortet worden.
LG
PW
Peter Köhlmann
May 9, 2013, 4:43:48 PM5/9/13
to
Paul-Wilhelm Hermsen wrote:
> Am 09.05.13 18:44, schrieb Helmut Hullen:
>> Folgeproblem: was ist mit dem Backup anzufangen, das vorzeitig abgewürgt
> Am 09.05.13 18:44, schrieb Helmut Hullen:
>> wurde?
>
> LOL
>
> Üblicher Weise nichts!
>
> Unter OS X haben wir es in case of Time Machine aber durchaus mit einem
> sehr intelligenten Datensicherungsmodell zu tun, dass ich um nichts mehr
> missen möchte. Das kann man ruhig abwürgen. Beim nächsten Mal wird an
> Unter OS X haben wir es in case of Time Machine aber durchaus mit einem
> sehr intelligenten Datensicherungsmodell zu tun, dass ich um nichts mehr
> der Stelle wieder angesetzt, an welcher das Backup zuletzt erfolgreich
> war.
Time Machine is Müll. Alleine schon die üble Art, wie Backups gespeichert
> war.
werden ist ein Grund, die gesamte Entwicklertruppe direkt an die Wand zu
stellen.
Wer sich solch gefährlichen Humbug wie Hardlinks auf Directories (!!)
ausdenkt hat nicht mehr alle Tassen im Schrank.
Und du bist hier nicht in einer OSX-Gruppe.
Peter Köhlmann
May 9, 2013, 4:52:13 PM5/9/13
to
Paul-Wilhelm Hermsen wrote:
> Am 09.05.13 22:22, schrieb Marc Haber:
>
>> Wo hast Du eigentlich geschrieben, dass es um MacOS und nicht um Linux
>> geht?
>
> Nirgendwo - spielt eigentlich, abgesehen von gewissen Sonderheiten,
> keine Rolle.
Doch, tut es. Simple Scripte laufen unverändert. Bei komplexeren Sachen
> Am 09.05.13 22:22, schrieb Marc Haber:
>
>> Wo hast Du eigentlich geschrieben, dass es um MacOS und nicht um Linux
>> geht?
>
> Nirgendwo - spielt eigentlich, abgesehen von gewissen Sonderheiten,
> keine Rolle.
stimmt das nicht mehr so ohne Weiteres
Längst nicht alle Parameter sind identisch oder fehlen sogar völlig
>> Und warum fragst Du in einer Linuxgruppe?
>
> Soll ich Dir das jetzt wirklich ernsthaft beantworten, ohne mich bei den
> OS Xlern ins Abseits zu manövrieren?
überwiegende Mehrzahl der OSXler ihren Arsch nicht von einem Loch im Boden
unterscheiden könnten
Deswegen wird man in einer solchen Gruppe meist auch keine sinnvollen
Antworten bekommen
Paul-Wilhelm Hermsen
May 9, 2013, 4:56:03 PM5/9/13
to
Ach - guten Abend, Herr Köhlmann.
Wie ist Ihr Befinden?
Schon Jahre nichts mehr von Ihnen gehört.
Wie ist Ihr Befinden?
Schon Jahre nichts mehr von Ihnen gehört.
Paul-Wilhelm Hermsen
May 9, 2013, 5:01:22 PM5/9/13
to
Am 09.05.13 22:52, schrieb Peter Köhlmann:
Was sollte sich auch geändert haben?
> Wäre ja mal ein Anfang. Zum Beispiel könntest du ruhig zugeben, dass die
> überwiegende Mehrzahl der OSXler ihren Arsch nicht von einem Loch im Boden
> unterscheiden könnten
> Deswegen wird man in einer solchen Gruppe meist auch keine sinnvollen
> Antworten bekommen
Ich sehe - ist alles roger bei Ihnen.
> überwiegende Mehrzahl der OSXler ihren Arsch nicht von einem Loch im Boden
> unterscheiden könnten
> Deswegen wird man in einer solchen Gruppe meist auch keine sinnvollen
> Antworten bekommen
Was sollte sich auch geändert haben?
Jakob Schürz
May 9, 2013, 5:32:57 PM5/9/13
to
Am 2013-05-09 15:52, schrieb Paul-Wilhelm Hermsen:
> Am 09.05.13 15:10, schrieb Marc Haber:
>
>> Der einfache Weg wäre sicherzustellen, dass Command 2 im Vordergrund
> Am 09.05.13 15:10, schrieb Marc Haber:
>
>> bleibt, bis das Backup abgeschlossen ist.
Ich hab mir für FVWM ein Skript geschrieben, welches ein Icon grün oder
rot anzeigt, je nachdem, ob das daemonisierte fetchmail gerade Mails
abruft, oder nicht.
Dazu der essentielle Code, wo ich genau das rausfinde:
grep SigIgn /proc/$(pidof fetchmail &)/status|cut -c 22
Vielleicht hilfts ja.
lg jakob
--
"Die Zuweisung erfolgt mit hoher Priorität und schläft nicht. Dies ist
die Flagge, um Einsatz in Interrupt-Handler, unten Hälften und andere
Situationen, in denen Sie kann nicht schlafen."
(aus http://de.how-to.mobi/index.php?id=116343)
http://xundeenergie.wordpress.com
werts...@nurfuerspam.de
Martin Vaeth
May 10, 2013, 4:16:05 AM5/10/13
to
Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
> Aus "man bash":
>
> wait [n ...]
Das ist für Kind-Prozesse gedacht. Es ist unklar, ob das
>
> wait [n ...]
bei den OSX-Selbstdämonisierungen der Fall ist.
Peter J. Holzer
May 10, 2013, 4:26:30 AM5/10/13
to
On 2013-05-09 19:46, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
> Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
>> z.B.
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
> oder, bei Verwendung der bash zumindest (sollten andere shells aber auch
> k�nnen, da POSIX), "wait".
> Aus "man bash":
>
> wait [n ...]
> Wait for each specified process and return its termination
> status. Each n may be a process ID or a job specification;
> if a job spec is given, all processes in that job's
> pipeline are waited for. If n is not given, all currently
> active child pro- cesses are waited for, and the return
> status is zero. If n specifies a non-existent process or job,
> the return status is 127. Otherwise, the return status
> is the exit status of the last process or job waited for.
wait kann nur auf Kindprozesse warten, nicht auf beliebige Prozesse.
> Du schriebst am Thu, 09 May 2013 17:41:47 +0200:
>> z.B.
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>
> oder, bei Verwendung der bash zumindest (sollten andere shells aber auch
> k�nnen, da POSIX), "wait".
> Aus "man bash":
>
> wait [n ...]
> Wait for each specified process and return its termination
> status. Each n may be a process ID or a job specification;
> if a job spec is given, all processes in that job's
> pipeline are waited for. If n is not given, all currently
> active child pro- cesses are waited for, and the return
> status is zero. If n specifies a non-existent process or job,
> the return status is 127. Otherwise, the return status
> is the exit status of the last process or job waited for.
> Damit sollte ein "wait $PID" mit der PID des Backup-Prozesses in PID
> reichen.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpa�t. -- Ralph Babel
Helmut Hullen
May 10, 2013, 4:52:00 AM5/10/13
to
Hallo, Sieghard,
Du meintest am 09.05.13:
[...]
Testprogramm "warte":
#! /bin/bash
date > /var/log/warte.log
mach-back hourly Arktur &
sleep 5
Pid=$(pgrep mach-back | head -1)
wait $Pid
date >> /var/log/warte.log
#
Aufruf mit
bash -x warte
liefert
+ date
+ mach-back hourly Arktur
++ pgrep mach-back
+ Pid=32541
+ wait 32541
warte: Zeile 6: wait: Proze� 32541 wurde nicht von dieser Shell gestartet.
+ date
#########
Schade ...
Du meintest am 09.05.13:
[...]
>> z.B.
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
> oder, bei Verwendung der bash zumindest (sollten andere shells aber
> auch k�nnen, da POSIX), "wait".
> Aus "man bash":
> wait [n ...]
> Wait for each specified process and return its
> termination status.
K�nnte sein, dass das in diesem Fall nicht funktioniert:
>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
> oder, bei Verwendung der bash zumindest (sollten andere shells aber
> auch k�nnen, da POSIX), "wait".
> Aus "man bash":
> wait [n ...]
> Wait for each specified process and return its
> termination status.
Testprogramm "warte":
#! /bin/bash
date > /var/log/warte.log
mach-back hourly Arktur &
sleep 5
Pid=$(pgrep mach-back | head -1)
wait $Pid
date >> /var/log/warte.log
#
Aufruf mit
bash -x warte
liefert
+ date
+ mach-back hourly Arktur
++ pgrep mach-back
+ Pid=32541
+ wait 32541
warte: Zeile 6: wait: Proze� 32541 wurde nicht von dieser Shell gestartet.
+ date
#########
Schade ...
Peter J. Holzer
May 10, 2013, 5:19:56 AM5/10/13
to
On 2013-05-10 08:16, Martin Vaeth <va...@mathematik.uni-wuerzburg.de> wrote:
> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>>
>> Aus "man bash":
>>
>> wait [n ...]
>
> Das ist f�r Kind-Prozesse gedacht. Es ist unklar, ob das
> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>>
>> Aus "man bash":
>>
>> wait [n ...]
>
> bei den OSX-Selbstd�monisierungen der Fall ist.
Es kann nicht der Fall sein.
Wenn Du ein Programm in der Shell ohne & hintendran startest, dann macht
die Shell folgendes:
1. Erzeugt einen Kindprozess
2. Kindprozess exect das Programm
3. Vaterprozess (Shell) wartet auf den Kindprozess.
Wenn Du zur Shell zur�ckkommst, hat die also bereits erfolgreich auf den
Kindprozess gewartet - der Kindprozess existiert nicht mehr und man kann
nicht noch einmal auf den warten.
Die einzige M�glichkeit, die ein Programm hat, sich selbst "in den
Hintergrund zu stellen", ist seinerseits zu forken und den Vaterprozess
zu beenden. Aber dann ist der neue Kindprozess kein Kindprozess der
Shell mehr (sondern ein Enkel) und die Shell kann nicht auf den warten.
Juergen Ilse
May 10, 2013, 5:24:37 AM5/10/13
to
Hallo,
Martin Vaeth <va...@mathematik.uni-wuerzburg.de> wrote:
> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>>
>> Aus "man bash":
>>
>> wait [n ...]
>
> Das ist fï¿œr Kind-Prozesse gedacht. Es ist unklar, ob das
> bei den OSX-Selbstdï¿œmonisierungen der Fall ist.
Es funktioniert auch nur bei child-prozessen der shell, und es ist zu
vermuten, dass das bei dem beschriebenen Szenario nicht der Fall seinwird ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Martin Vaeth <va...@mathematik.uni-wuerzburg.de> wrote:
> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>>> while pgrep [PID]; do sleep [Zeit in Sekunden]; done
>>
>> Aus "man bash":
>>
>> wait [n ...]
>
> bei den OSX-Selbstdï¿œmonisierungen der Fall ist.
Es funktioniert auch nur bei child-prozessen der shell, und es ist zu
vermuten, dass das bei dem beschriebenen Szenario nicht der Fall seinwird ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Moderator
May 10, 2013, 5:51:25 AM5/10/13
to
On 9 Mai, 19:30, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote:
> Merkst Du einklich [1] noch was? [2]
Unterlasse doch bitte Deine sinnfreien fups nach dsu
> Merkst Du einklich [1] noch was? [2]
F.W.
(Moderator)
Moderator
May 10, 2013, 5:54:25 AM5/10/13
to
On 9 Mai, 20:52, Peter Köhlmann <peter-koehlm...@t-online.de> wrote:
> Thomas 'PointedEars' Lahn wrote:
>> [wiedermal Müll]
> Du erzeugst mit deinem Müll mehr Off-Topic Posts als alle (eventuell
> leicht) OT-Posts die in Monaten zusammenkommen
Unterlasse es doch bitte, den Troll in de.soc.usenet zu füttern.
Danke.
F.W.
(Dsu-Moderator)
> Thomas 'PointedEars' Lahn wrote:
>> [wiedermal Müll]
> Du erzeugst mit deinem Müll mehr Off-Topic Posts als alle (eventuell
> leicht) OT-Posts die in Monaten zusammenkommen
Unterlasse es doch bitte, den Troll in de.soc.usenet zu füttern.
Danke.
F.W.
(Dsu-Moderator)
Paul-Wilhelm Hermsen
May 10, 2013, 2:26:59 PM5/10/13
to
Nur zur Info, weil mir hier durch den Thread die Skriptologie n�her
gebracht wurde.
PW="$(osascript -e 'yes '' | tell application "System Events" to display
dialog "Password:" default answer "MEINPASSWORT" with hidden answer' -e
'text returned of result' 2>/dev/null)"
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
# echo "$PW" | sudo -S
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
Das war die Zeile, welche das Backup zum D�monprozess werden lie�. Die
habe ich verworfen.
echo "$PW" | sudo -S tmutil startbackup -b
Diese Zeile, allerdings urspr�nglich ohne die -b Option, hat denselben
Prozess in den Vordergrund treten lassen, so dass
ich dort nach Abfrage der PID und Warteschleife, wie nachfolgend
beschrieben, bereits den gew�nschten Erfolg erzielen konnte.
Die jetzt angeh�ngte - b Option (--block) bewirkt, dass ich noch nicht
einmal PID und Warteschleife ben�tige, denn
#pgrep -l -x backupd > /dev/null
#while pgrep -l -x backupd > /dev/null
# do
# sleep 60
# done
jetzt wartet der folgende Befehl auf die Beendigung der Datensicherung,
wird also solange geblockt.
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Also sieht das fertige Produkt jetzt so aus:
#sudo Passwort in eine Variable packen
PW="$(osascript -e 'yes '' | tell application "System Events" to display
dialog "Password:" default answer "MEINPASSWORT" with hidden answer' -e
'text returned of result' 2>/dev/null)"
#Spotlight D�mon stoppen (Ist nach einem Reboot wieder aktiv.)
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
#Datensicherung starten und Ende abwarten
echo "$PW" | sudo -S tmutil startbackup -b
#Spotlight D�mon vor einem Reboot wieder starten
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Der erste Block �bersetzt im Kern eine Anweisung aus einem Appleskript
in ein Shellskript. Da w�rde im Falle der fehlenden <yes''> Anweisung
ein Popup sichtbar werden, welches bereits MEINPASSWORT enth�lt. Mit
osascript lassen sich Appleskripte in Shellskripte einf�gen. <yes''>
bewirkt allerdings ein RETURN, so dass das Popup gar nicht sichtbar
wird. Will ich mein Passwort nach Shellskriptstart im Popupfenster
eingeben, muss <yes''> entfernt werden und MEINPASSWORT leer bleiben.
Ohne Schleife ist der Datensicherungsprozess erstaunlicher Weise noch
sp�rbar schneller geworden.
Danke f�r die Hilfen an dieser Stelle!
LG
PW
gebracht wurde.
PW="$(osascript -e 'yes '' | tell application "System Events" to display
dialog "Password:" default answer "MEINPASSWORT" with hidden answer' -e
'text returned of result' 2>/dev/null)"
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
# echo "$PW" | sudo -S
/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd-helper
Das war die Zeile, welche das Backup zum D�monprozess werden lie�. Die
habe ich verworfen.
echo "$PW" | sudo -S tmutil startbackup -b
Diese Zeile, allerdings urspr�nglich ohne die -b Option, hat denselben
Prozess in den Vordergrund treten lassen, so dass
ich dort nach Abfrage der PID und Warteschleife, wie nachfolgend
beschrieben, bereits den gew�nschten Erfolg erzielen konnte.
Die jetzt angeh�ngte - b Option (--block) bewirkt, dass ich noch nicht
einmal PID und Warteschleife ben�tige, denn
#pgrep -l -x backupd > /dev/null
#while pgrep -l -x backupd > /dev/null
# do
# sleep 60
# done
jetzt wartet der folgende Befehl auf die Beendigung der Datensicherung,
wird also solange geblockt.
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Also sieht das fertige Produkt jetzt so aus:
#sudo Passwort in eine Variable packen
PW="$(osascript -e 'yes '' | tell application "System Events" to display
dialog "Password:" default answer "MEINPASSWORT" with hidden answer' -e
'text returned of result' 2>/dev/null)"
#Spotlight D�mon stoppen (Ist nach einem Reboot wieder aktiv.)
echo "$PW" | sudo -S launchctl unload
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
#Datensicherung starten und Ende abwarten
echo "$PW" | sudo -S tmutil startbackup -b
#Spotlight D�mon vor einem Reboot wieder starten
echo "$PW" | sudo -S launchctl load
/System/Library/LaunchDaemons/com.apple.metadata.mds.plist
Der erste Block �bersetzt im Kern eine Anweisung aus einem Appleskript
in ein Shellskript. Da w�rde im Falle der fehlenden <yes''> Anweisung
ein Popup sichtbar werden, welches bereits MEINPASSWORT enth�lt. Mit
osascript lassen sich Appleskripte in Shellskripte einf�gen. <yes''>
bewirkt allerdings ein RETURN, so dass das Popup gar nicht sichtbar
wird. Will ich mein Passwort nach Shellskriptstart im Popupfenster
eingeben, muss <yes''> entfernt werden und MEINPASSWORT leer bleiben.
Ohne Schleife ist der Datensicherungsprozess erstaunlicher Weise noch
sp�rbar schneller geworden.
Danke f�r die Hilfen an dieser Stelle!
LG
PW
Ansgar Strickerschmidt
May 13, 2013, 5:59:04 AM5/13/13
to
Also schrieb Paul-Wilhelm Hermsen:
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
>
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
>
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
> b) weil die Datensicherung beendet ist, Command 3 ausgefï¿œhrt wird.
Du lï¿œsst die Datensicherung (vmtl. nicht nur ein Binï¿œr-Kommando, sondern
seinerseits bestimmt ein Skript) einen Wert -also vorzugsweise sowas wie
einen numerischen Return Code- in eine Named Pipe schreiben, an der das
Skript lauscht, das den Daemon an- und abschaltet.
Das war jetzt aber einfach.
Ansgar
--
*** Musik! ***
> Skriptnovice schreibt:
>
> Ich habe ein Skript folgender Art
>
> Command 1 (Daemon abschalten)
> Command 2 (Datensicherung anwerfen)
> Command 3 (Daemon anschalten)
>
> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>
> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
> stellen, dass
> a) die Datensicherung beendet ist und
> b) weil die Datensicherung beendet ist, Command 3 ausgefï¿œhrt wird.
Du lï¿œsst die Datensicherung (vmtl. nicht nur ein Binï¿œr-Kommando, sondern
seinerseits bestimmt ein Skript) einen Wert -also vorzugsweise sowas wie
einen numerischen Return Code- in eine Named Pipe schreiben, an der das
Skript lauscht, das den Daemon an- und abschaltet.
Das war jetzt aber einfach.
Ansgar
--
*** Musik! ***
Thomas 'PointedEars' Lahn
May 13, 2013, 7:39:45 AM5/13/13
to
Ansgar Strickerschmidt wrote:
> Also schrieb Paul-Wilhelm Hermsen:
>> Skriptnovice schreibt:
>>
>> Ich habe ein Skript folgender Art
>>
>> Command 1 (Daemon abschalten)
>> Command 2 (Datensicherung anwerfen)
>> Command 3 (Daemon anschalten)
>>
>> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
>> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>>
>> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
>> stellen, dass
>> a) die Datensicherung beendet ist und
>> b) weil die Datensicherung beendet ist, Command 3 ausgeführt wird.
> Also schrieb Paul-Wilhelm Hermsen:
>> Skriptnovice schreibt:
>>
>> Ich habe ein Skript folgender Art
>>
>> Command 1 (Daemon abschalten)
>> Command 2 (Datensicherung anwerfen)
>> Command 3 (Daemon anschalten)
>>
>> Jetzt soll Command 3 aber erfolgen, wenn die Datensicherung, welche z.T.
>> recht lange dauert, beendet ist. Und genau das ist mein Problem.
>>
>> Wie kann ich zwischen Command 2 und Command 3 skriptologisch sicher
>> stellen, dass
>> a) die Datensicherung beendet ist und
>
> Du lässt die Datensicherung (vmtl. nicht nur ein Binär-Kommando, sondern
> seinerseits bestimmt ein Skript) einen Wert -also vorzugsweise sowas wie
> einen numerischen Return Code- in eine Named Pipe schreiben, an der das
> Skript lauscht, das den Daemon an- und abschaltet.
>
> Das war jetzt aber einfach.
Das wäre so einfach, wenn a) Deine unbegründete Vermutung bezüglich der
> einen numerischen Return Code- in eine Named Pipe schreiben, an der das
> Skript lauscht, das den Daemon an- und abschaltet.
>
> Das war jetzt aber einfach.
Datensicherung zuträfe, es b) ein solches Skript gäbe, und c) wenn der
Ansatz, ein solches “lauschendes Skript” zu haben, grundsätzlich sinnvoll
wäre.
--
PointedEars
0 new messages