Mailinglist Archive: opensuse-de (4938 mails)

< Previous Next >
Re: Jobkontrolle
  • From: B.Brodesser@xxxxxxxxxxxxxx (Bernd Brodesser)
  • Date: Mon May 29 09:18:08 2000
  • Message-id: <20000529111808.E22505@xxxxxxxxxxxxxx>



* Eilert Brinkmann schrieb am 29.Mai.2000:
"Matthias Kleine" <Matthias.Kleine@xxxxxxxxxxxx> wrote:

Richtig. Der sleep-Prozeß bekommt ein Signal und wird gestoppt. Das
trifft ihn mitten in dem Systemaufruf nanosleep. (Eigentlich benutzt
das Programm sleep(1) die Bibliotheksfunktion sleep(3), aber die
greift intern wieder auf den Systemaufruf nanosleep(2) zurück.)

Das ist offensichtlich richtig, obwohl in man 3 sleep von nanosleep
nicht die Rede ist, dort wird nur alarm(2) erwähnt. Dient wohl nur zur
verwirrung, denn alarm wird definitiv nicht aufgerufen.

matthias@orka:~ > bg %1
[1]+ sleep 1000 &

Nun bekommt der Prozeß ein anderes Signal und wird fortgesetzt. Da der
nanosleep-Aufruf durch ein Signal unterbrochen wurde, kehrt er sofort
mit einer Fehlermeldung (errno == EINTR) zurück, bevor die Zeit
abgelaufen ist.

Wenn ich es richtig verstanden habe, so hat aber nanosleep gerade
dafür den zweiten Eintrag. Damit sollte es doch zu bewerkstelligen
sein, daß nanosleep neu gestartet wird.

Langsam verstehe ich auch das Problem dahinter. Anders als die meisten
Signale führen die Signale 18, 19 und 20 standardmäßig nicht zum
Abbruch eines Prozesses. Stattdessen wird ein Prozeß bei Signal 19
oder 20 angehalten und bei Signal 18 weitergeführt.

Würde es sleep bzw. nanosleep genauso machen, käme ihre Zeit
durcheinander. Denn die Zeit, wo der Prozeß angehalten ist, würde
nicht mitgezählt. Dafür hat nanosleep den zweiten Eintrag. Aber
irgendwie klappt das mit sleep nicht. Oder habe ich es doch nicht
richtig verstanden.

Richtig. Denn sleep wurde offenbar nicht so programmiert, daß nach
der Störung noch wieder die verbleibende Zeit gewartet
wird. Stattdessen beendet sich sleep, egal, warum der nanosleep-Aufruf
zurückkehrt. Das läßt sich sogar halbwegs mit einem strace beobachten:

[...]

-> tail -5 bla
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0

rt_sigprocmask ist offensichtlich ein Systemaufruf, aber
man rt_sigprocmask sagt nur:

Kein Manual-Eintrag für rt_sigprocmask vorhanden

Sch... Manual. In /usr/src/linux/Documentation habe ich auch nichts
gefunden. Weiß nicht, wo ich noch suchen könnte.

rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0

Für rt_sigaction gilt das Gleiche. Aber SIGCHLD hat mich auf die Idee
gebracht strace ein -f mitzugeben.

rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1000, 0}, 0xbffff07c) = -1 EINTR (Interrupted system call)
^^^^^^^^^^
Was will uns das sagen? Offensichtlich eine Adresse, aber worauf?

_exit(0) = ?

Ich habe mal strace -f -o bla sleep 1000 gemacht mit anschließendem im
Hintergrundschicken:

4736 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
4736 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
4736 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
4736 nanosleep({1000, 0}, <unfinished ...>
4736 --- SIGCONT (Fortgesetzt) ---
4736 <... nanosleep resumed> 0xbffff5ec) = -1 ENOSYS (Function not
implemented)

Hier also ist der SIGCONT zu finden. Aber warum nur hier, und ein Kind
habe ich auch nicht gefunden, überall nur die gleiche Prozeßnummer,
das ganze strace lang.

Das SIGCONT kommt also im nanosleep, was auch nicht weiter überrascht.
nanosleep gibt ein ENOSYS zurück, womit sleep nichts anfangen kann und
daher abbricht. Das heißt, sleep bekommt es gar nicht mehr zu Gesicht,
oder? Sonst würde da doch ein _exit stehen. Aber ohne -f gibt strace
auch ein _exit aus. Was denn jetzt?

Irgendwie bin ich jetzt noch verwirrter.

Kann mir das jemand erklären? Wie kann ich den Job aus dem Vordergrund
in den Hintergrund schicken, wenn es mit C-Z und bg %Jobnummer nicht
klappt?

Deine Vorgehensweise war schon richtig, aber manchmal haben solche
Aktionen eben ungewünschte Nebenwirkungen :-(

Einfach die Zeit, die der Prozeß angehalten war zu übergehen, wäre
sicher auch nicht richtig, aber so ist es sicher falsch.

Bernd


--
Homepages von deutschsprachigen Linux-Gurus:
Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/
Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven
Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10

---------------------------------------------------------------------
To unsubscribe, e-mail: suse-linux-unsubscribe@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx


< Previous Next >
References