Prozesse

[Mel]

Hi Leute,

seit Tagen zerbreche ich mir bereits den Kopf wegen einer bestimmten Sache und ich komme einfach nicht dahinter, wieso sich Debian resp. Linux hier so verhält, wie es sich verhält:

Ich hör schonmal gerne ein Hörspiel zum Einschlafen, will aber nicht, dass mein Rechner die ganze Nacht dann an ist. Deshalb lasse ich nebenher einen XTerm laufen mit den Befehlen "sleep 5000; shutdown -h now". Klappt auch wie erwartet.
Was ich mir nicht erklären kann, ist, dass mein Rechner sofort herunterfährt, wenn ich den XTerm vor Ablauf der 5000 Sekunden schliesse. Ich bin eigentlich eher davon ausgegangen, dass dann alle Befehle, die in der XTerm-Shell laufen, abgebrochen werden sollten. Der sleep-Befehl wird ja auch nicht mehr zu Ende ausgeführt. Nur *wieso* (zum Teufel) wird der shutdown-Befehl überhaupt noch ausgeführt? Ich habe ihm doch eigentlich die Shell unter den Füssen weggezogen..

Die Sache macht mich wirklich fertig.
Kann sich das jemand von Euch erklären?

Gruss,
Mel.

PS: Das einzige, was ich mir denken könnte, ist, dass der shutdown-Befehl aufgrund irgendwelcher Hooks eine spezielle Behandlung erfährt... *grübel*

[gms]

warum verwendest du nicht "shutdown -h +90" (...in 90 Minuten)

Ich vermute, daß shutdown kein Terminal benötigt und daher auch nicht terminiert.

[Master Mayhem]

mhh könnte mir vorstellen, dass shutdown in der xshell immer mit nohup gestarted wird (über ein alias), weil es sonst ja auch nie funktionieren würde, weil durch das killen der xshell, bzw der ganzen x-session, was nötig ist zum runterfahren, der prozess immer gestoppt werden würde, wenn die xshell geschlossen wird

Was dann bei dir passiert, ist dass der sleep befehl von der xshell-pid abhängt, also für sleep die ppid die xshell ist (während mit nohup der prozess direkt an den init prozess angehängt wird also als ppid die 1 hat) und wenn sleep gekillt wird, wird der bisher gestoppte prozess (durch sleep) sofort ausgeführt, weil dieser unabhängig von der xshell laufen kann und nur darauf wartet, dass die pid vom sleep prozess verschwindet

bin mir nicht 100% sicher aber ich finde dass sich das logisch anhört
http://www.linuxfibel.de/proccontrol.htm#ohne

ich verwende übrigens ein at now +2 hours gebe halt ein und Strg-D fertig, wenn ich mir die erstellte datei dann ansehe, vermute ich dass der sich zur angegebenen zeit einfach selber ne shell aufmacht und halt ausführt...könnte ich eigentlich mal testen, was passiert wenn ich die xshell vorher schließe, das hab ich noch nie bewußt ausprobiert und mit nohup gebe ich das nie ein
glaub aber auch, dass at da anders arbeitet, ähnlich wie cron mit nem daemon, dem das eh scheißegal ist welche shell gerade offen ist oder nicht

mfg tyler

[meandtheshell]

Ich hör schonmal gerne ein Hörspiel zum Einschlafen, will aber nicht, dass mein Rechner die ganze Nacht dann an ist. Deshalb lasse ich nebenher einen XTerm laufen mit den Befehlen "sleep 5000; shutdown -h now". Klappt auch wie erwartet.
Was ich mir nicht erklären kann, ist, dass mein Rechner sofort herunterfährt, wenn ich den XTerm vor Ablauf der 5000 Sekunden schliesse. Ich bin eigentlich eher davon ausgegangen, dass dann alle Befehle, die in der XTerm-Shell laufen, abgebrochen werden sollten. Der sleep-Befehl wird ja auch nicht mehr zu Ende ausgeführt.Nur *wieso* (zum Teufel) wird der shutdown-Befehl überhaupt noch ausgeführt?

Code: Alles auswählen

sleep 5000; shutdown -h now

was hier passiert ist vollkommen klar - damit erreichst du das du der bash eine liste übergibts - d.h. zuerst führt sie

Code: Alles auswählen

sleep 5000

sie wartet also 5000 sec
wenn du während dieser phase auf ein anderes terminal wechselst und dann

Code: Alles auswählen

ps -ef

machst
siehst du das der sleep prozess gestartet ist und läuft und das sein Parentprozess die bash (allgemeiner shell) ist in der er gesartet wurde

nach ablauf der zeit oder beenden der bash wird das zweite kommando in der liste ausgeführt es sei den du brichst den ersten prozess also sleep 5000 mit [Strg]+[C] ab - das führt dazu das die liste nicht mehr bis zum ende abgearbeitet wird

[gms]

Nohup ignoriert Hangup Signale und stellt einem terminalabhängigen Prozeß ein "Ersatzterminal" zur Verfügung.
Programme (Stichwort Daemons) können gleiches auch selbständig erreichen, indem sie die Standard Filedescriptoren schließen, den Prozeß forken und dann den Vaterprozeß terminieren lassen .
Das Shutdown Programm nutzt jedoch weder nohup, noch verfällt es eigenständig in einen Daemon-Modus. Es scheint so, als hätte "shutdown -h now" einfach so wenig zu tun, daß sich das noch rechtzeitig ausgeht. Im wesentlichen werden nur ein paar Logeinträge erstellt und danach "/sbin/init 0" aufgerufen.

Die relevanten Teile von "strace shutdown -h now >x.log" :

Code: Alles auswählen

rt_sigaction(SIGPIPE, {0xb7f7f530, [], 0}, {SIG_DFL}, 8) = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
send(3, "<13>Mar  9 23:16:39 shutdown[300"..., 66, 0) = 66
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
close(3)                                = 0
unlink("/var/run/shutdown.pid")         = 0
unlink("/etc/nologin")                  = -1 ENOENT (No such file or directory)
sync()                                  = 0
rt_sigaction(SIGALRM, {0x8049ac0, [], 0}, NULL, 8) = 0
alarm(3)                                = 0
open("/dev/initctl", O_WRONLY)          = 3
write(3, "i\31\t\3\6\0\0\0\0\0\0\0\0\0\0\0INIT_HALT\0\0\0\0\0\0\0"..., 384) = 384
close(3)                                = 0
alarm(0)                                = 3
execve("/sbin/init", ["/sbin/init", "0"], [/* 30 vars */]) = 0

[meandtheshell]

@gms
zuerst einmal nette grüsse an einen landsman

Nohup ignoriert Hangup Signale und stellt einem terminalabhängigen Prozeß ein "Ersatzterminal" zur Verfügung.

das kommando nohup koppelt Programme von der shell ab - nohup schirmt also sozusagen den prozess von den HUP signalen der shell ab. was meinst du mit ersatzterminal - der prozess läuft ja weiter und ist über signale und deskriptoren zu erreichen

Programme (Stichwort Daemons) können gleiches auch selbständig erreichen, indem sie die Standard Filedescriptoren schließen, den Prozeß forken und dann den Vaterprozeß terminieren lassen .

wenn ich einen prozess forke dann erzeuge ich ja einen neuen - so wie ich das verstehe meinst du das sich ein prozess selber forkt was ich wiederum nicht verstehe - wie meinst du das?

ich habe gesehen das du in der software entwicklung tätig bist und das sicher schon viele jahre oder so - du hast also denke ich mehr anhnung/praxis wie auch immer und kannst mir vielleicht über mein verständnis problem hinweg helfen - danke !

markus

[Master Mayhem]

Es scheint so, als hätte "shutdown -h now" einfach so wenig zu tun, daß sich das noch rechtzeitig ausgeht. Im wesentlichen werden nur ein paar Logeinträge erstellt und danach "/sbin/init 0" aufgerufen.

Das heißt das unmounten und das killen des init prozeßes (wodurch alle anderen prozesse natürlich auch mit draufgehen) wird von /sbin/init 0 durchgeführt, was am ende der nötigen schreiboperationen aufgerufen wird?

Hört sich etwa grob an...wird der unmount der eingehängten partitionen denn auch noch von shutdown -h now durchgeführt oder von /sbin/init 0?

mfg tyler

[gms]

Hört sich etwa grob an...wird der unmount der eingehängten partitionen denn auch noch von shutdown -h now durchgeführt oder von /sbin/init 0?

unmount wird vom Script "/etc/init.d/umountfs" ausgeführt, welches wiederum vom init-Prozeß ( /etc/rc0.d/S40umountfs ) aufgerufen wird.
shutdown braucht nur die User zu informieren, den shutdown-Event zu loggen und /sbin/init 0 aufzurufen.
Ist ja auch eigentlich sinnvoll, daß "init 0" das System genauso korrekt herunterfährt wie "shutdown -h now"

[Master Mayhem]

Thx!

Ich kann zwar nicht behaupten, dass ich das schon alles verstanden habe, aber es gibt einen guten einstieg....wie ein System V bootet bzw runterfährt (was einfacher zu verstehen sein soll als das booten) finde ich mit am interessantesten - aber da muss ich noch mehr lesen

mfg tyler