Bash Skript wird zum Zombie - warum?

[MrToiz]

Hallo,
ich habe ein komisches Problem mit meinem Backup-Skript. Neulich habe ich es um einen Block erweitert und seitdem bleibt der Prozess immer hängen. ps aux zeigt dann immer nur an:

1:
2:
3:
4:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     23873  0.0  0.0  28384   952 ?        S    05:05   0:00 /USR/SBIN/CRON
root     23874  0.0  0.0      0     0 ?        Zs   05:05   0:00 [backup.sh] <defunct>
103      23891  0.0  0.0  42724  1904 ?        S    05:05   0:00 /usr/sbin/sendmail -i -FCronDaemon -oem root

Das komische daran ist jedoch, dass das Skript anscheinend ohne Probleme durchläuft. Zumindest habe ich an einigen Stellen (u.a. in der letzten Zeile des Skriptes) echo-Anweisungen platziert die in eine Log-Datei schreiben - und diese ist vollständig. Außerdem habe ich testweise mal den neuen Code-Block in ein eigenes Skript verpackt und dieses ausgeführt - funktioniert ebenfalls einwandfrei!
Bevor ich hier seitenweise Code poste - was hat dieses <defunct> überhaupt zu bedeuten?

Gruß,
MrToiz

[Daxalu]

mit defunct werden sogenannte Zombie Prozesse gekennzeichnet.
Diese sind eigentlich schon beendet wollen jedoch dem elternprozeß noch mitteilen, dass sie zuende sind.
Scheinbar rufst du irgendwelche unterscripte auf, die du dann nicht korrekt prüfst

(näheres zu defunct unter http://www.techfak.uni-bielefeld.de/...ix-zombie.html)

[MrToiz]

OK, von Zombies hab ich schonmal was gehört (und auch das Z im Statusfeld bemerkt)...aber:
Ist mein Bash-Skript selbst der Zombie oder ein vom Skript aufgerufenes Programm?
Eigentlich interpretiere ich die Ausgabe von ps so, dass das Skript der Zombie ist, aber da wäre dann doch der cron-Prozess zuständig, das Ende zu registrieren und den Job aus der Prozessliste zu löschen, oder?
Wie auch immer, hier mal der Code-Block, der dieses Verhalten offenbar auslöst:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
if [ $NAME = "virtualbox" ] ; then
/etc/init.d/vbox-Win2k8Srv stop
/sbin/lvcreate --autobackup n --size 90G --snapshot --name vbox-snapshot /dev/main/vbox > /dev/null 2>&1
/etc/init.d/vbox-Win2k8Srv start
mkdir -p -m 700 /tmp/snapshots/virtualbox
mount /dev/main/vbox-snapshot /tmp/snapshots/virtualbox
rsync --archive --delete --filter="merge_"`dirname $0`"/filter" --stats --log-file=$BASE/$NAME.log /tmp/snapshots/virtualbox $BASE/$NAME/ > /dev/null
umount /tmp/snapshots/virtualbox
/sbin/lvremove --autobackup n -f /dev/main/vbox-snapshot > /dev/null 2>&1
rm -rf /tmp/snapshots/virtualbox
continue
fi

(Das ganze läuft in einer Schleife, darum der continue-Befehl am Schluss)

/etc/init.d/vbox-Win2k8Srv ist übrigens auch ein von mir geschriebenes Skript, könnte da der Fehler leigen?

Da hab ich das Debian-Skeleton genommen und die Start/Stop-Funktion folgendermaßen angepasst:

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
do_start()
{
	su -c "VBoxManage --nologo list runningvms | grep  \"\\\"$VMNAME\\\"\"" $USER > /dev/null \
		&& return 1
	su -c "/usr/bin/VBoxHeadless -startvm $VMNAME >> /var/log/$NAME.log &" $USER \
		|| return 2
}

do_stop()
{
	su -c "VBoxManage --nologo list runningvms | grep  \"\\\"$VMNAME\\\"\"" $USER > /dev/null \
		|| return 1
	su -c "VBoxManage --nologo controlvm $VMNAME savestate > /dev/null" $USER
	RETVAL="$?"
	return "$RETVAL"
}

Sollte da im Start-Block noch ein return 0 ans Ende gepackt werden?

Trotz allem nochmal der Hinweis: Packe ich den oben geposteten Backup-Code in ein eigenes Skript und führe dieses aus, läuft es ohne Probleme durch und mutiert nicht zum Zombie. (Wie) ist das zu erklären?

Gruß,
MrToiz