ubuntuusers.de

Hallo,

irgendwas ist hier unter Ubuntu seltsam, was ich nicht verstehe.
Weil in einem größeren Programm eine Schleife, wie sie unten vorkommt, bei mir Probleme gemacht hat, habe ich mich mit wait und trap beschäftigt, komme aber nicht mehr weiter. Die Schleife wurde laut Entwickler wohl für den Betrieb unter Cygwin eingeführt – das installiere ich gerade und werde damit mal noch testen. Vielleicht hat jemand von euch eine bessere Lösung für das ganze.

Der Text:

Die erste Zeile

#!/bin/sh

oder

#!/bin/bash

tausche ich je nach Test um.

# traptest.sh

# Start two processes and save their PID
`sleep 2h` &
ONE=$!
echo \$ONE = $ONE

`sleep 2h` &
TWO=$!
echo \$TWO = $TWO

cleanup ()
{
        echo Stopping $ONE and $TWO
        kill $ONE $TWO
}

# CTRL-C
trap "echo signal 2; cleanup" 2

WAIT_STATUS=0
while [ $WAIT_STATUS -ne 127 ]
do
        wait $ONE
        WAIT_STATUS=$?
        echo huh? $WAIT_STATUS
        sleep 1
done

echo DONE

exit

Test mit /bin/dash bzw. /bin/sh
Version laut aptitude show: 0.5.4-8ubuntu1

Mit sleep

$ONE = 12726
$TWO = 12728
(ich drücke STRG-C)
signal 2
Stopping 12726 and 12728
huh? 130
huh? 143
huh? 127

Ohne sleep

$ONE = 12765
$TWO = 12767
(ich drücke STRG-C)
signal 2
Stopping 12765 and 12767
huh? 130
huh? 143
huh? 143
huh? 143
huh? 143
huh? 143
... (ich sage: kill -9 ps -A | grep traptest.sh | awk '{ print $1 }')
Killed

Test mit /bin/bash 3.2.39(1) Ubuntu Hardy

bash -version
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

(mit oder ohne sleep macht bis auf die Geschwindigkeit keinen Unterschied)

$ONE = 12804
$TWO = 12806
(ich drücke STRG-C)
signal 2
Stopping 12804 and 12806
./traptest2.sh: line 15: kill: (12804) - No such process
huh? 130
huh? -1
huh? -1
huh? -1
huh? -1
huh? -1
huh? -1
...
Killed

Test mit bash 2.05b.0(1) Suse Linux

Ich hab noch einen Rechner mit einer anderen bash:

bash -version
GNU bash, version 2.05b.0(1)-release (i586-suse-linux)
Copyright (C) 2002 Free Software Foundation, Inc.

Dort sieht der Programmablauf so aus (über ssh, aber das sollte ja keinen Unterschied machen?):

$ONE = 27209
$TWO = 27211
(ich drücke STRG-C)
signal 2
Stopping 27209 and 27211
huh? 130
^[1]- Unterbrechung sleep 2h
huh? 130
./traptest.sh: line 23: wait: pid 27209 is not a child of this shell
huh? 127
DONE

Wieso verhält sich die dash in dem Fall ohne sleep so seltsam, warum funktioniert es im Fall mit sleep? Warum verhält sich die bash in Version 3.2.39(1) noch seltsamer (meines Wissens sollte es in der shell keine negativen Exit-Werte geben)?

Test mit bash 3.2.39(19) cygwin 1.5.25-14

$ sh --version
GNU bash, version 3.2.39(19)-release (i686-pc-cygwin)
Copyright (C) 2007 Free Software Foundation, Inc.

$ bash --version
GNU bash, version 3.2.39(19)-release (i686-pc-cygwin)
Copyright (C) 2007 Free Software Foundation, Inc.

Ich hab das Script noch leicht abgeändert, damit dann mit "kill 2736" beenden konnte..

(Mit oder ohne sleep macht keinen Unterschied, wie oben)

$ ./traptest.sh
MyPID: 2736
$ONE = 3788
$TWO = 2084
signal 2
Stopping 3788 and 2084
./traptest.sh: line 16: kill: (3788) - No such process
./traptest.sh: line 16: kill: (2084) - No such process
huh? 130
huh? 130
huh? 130
huh? 130
huh? 130
huh? 130
...
Terminated

Was mich jetzt noch mehr verwundert ist folgendes Ergebnis, wenn ich statt "#!/bin/bash" "#!/bin/sh" in das Script schreibe – schließlich ist es angeblich das gleiche Programm (s.o. sh --version und bash --version...):

$ ./traptest.sh
MyPID: 2312
$ONE = 648
$TWO = 2712
signal 2
Stopping 648 and 2712
./traptest.sh: line 16: kill: (648) - No such process
./traptest.sh: line 16: kill: (2712) - No such process
huh? 130
huh? 130
./traptest.sh: line 24: wait: pid 648 is not a child of this shell
huh? 127
DONE

Letzteres ist seltsamerweise genau das Verhalten, was wohl ursprünglich vom Entwickler gedacht war... hmm.

Vielen Dank fürs Mitdenken

Jonas

Durfte gerade feststellen, dass

`sleep 2h` &

etwas übertrieben ist. Ich ändere es auf:

sleep 2h &

Damit ist dann der Fehler mit dem Rückgabewert -1 schonmal behoben...

Nun, es scheint, als wäre alles Verhalten der verschiedenen Shells so in Ordnung. Der Entwickler hat letztlich einfach die whileschleife verändert und ein paar mehr Abfragen für die einzelnen Shells eingeführt. Wen es interessiert:

http://jira.jboss.com/jira/browse/JBAS-4287#action_12419253

This new while loop covers the different variations of the wait command:

1) bash on Linux: when the bash run.sh process receives a termination signal, 1st call to wait returns an exit status >128 that represents the signal received, 2nd call to wait returns the exit status of the JBoss process itself (typically 0)

2) dash on Linux: same as above. NOTE: as an earlier comment in this issue described, dash's wait will infinitely return 0, even after the JBossAS process has exited (it should return 127 once the process no longer exists), unless a sleep is added to the loop. this is no longer an issue, since the loop's condition has been changed so the loop will terminate on any wait status <128

3) bash on CygWin: when the bash run.sh process receives a termination signal, 1st call to wait returns an exit status >128 that represents the signal *the bash process* received (I believe this is a bug in CygWin bash), 2nd call to wait returns an exit status >128 that represents the signal *the JBossAS process* received, 3rd call to wait returns the exit status of the JBoss process itself (typically 0)

4) sh on Solaris: 1st call to wait returns the exit status of the JBoss process itself (typically 0)