[linux-l] Weltzeituhr

[Steffen Dettmer]

* Peter Ross wrote on Wed, Nov 08, 2006 at 17:12 +1100:
> On Wed, 8 Nov 2006, Frank Reker wrote:
> 
> > wenn der vater nicht mehr existiert, dann wird der prozess kind 
> > von 1 (init). wenn sich der daemon (was daemonen normalerweise tun)
> > in den hintergrund forkt, dann gibt's den vater nicht mehr.
> > der aufruf sieht ueblicherweise so (oder so aehnlich) aus:
> > if (fork() > 0) exit (0);

ja, erstmal wenn schon, dann im switch :) Das forken ist auch nicht
wegen "Hintergrund", sondern damit setsid garantiert klappt (könnte
sonst schiefgehen, wenn's schon ne gleichnamige (pid) session gibt - hab
auch nicht verstanden, wie es dazu kommen kann, ausser setsid - execve,
was ja ziemlich weit hergeholt ist - aber dann könnte man rein
theoretisch "fremde" Kinder in der eigenen session hat). Soweit ich
weiss, jedenfalls. Das ppid ist IMHO eigentlich auch egal; weiss nicht,
ob man nicht bei setsid eh ppid == 1 hat; wichtig ist jedenfalls, kein
controlling terminal zu haben, wo nachher noch ein SIGINT oder SIGHUP
ankommt.

> Ach ja.. endlich ist der Groschen gefallen.. An das Forken _innerhalb_ 
> des Daemoncodes habe ich nicht gedacht.
> 
> Damit hat sich die Idee des offenen PID-Files wohl erledigt.

Ein "normaler" Daemon schützt sich natürlich genau vor sowas, in dem er
halt fork, setsid, close(all_file_no) macht; ist ein Feature :) Aber
/mein/ Daemon könnte natürlich sein PID File offen halten.

Oder man lebt halt mit extrem seltenen komischen Fällen.
pthread-dead-locks find ich schlimmer...

> Zurueck zum Ausgang: /var/run wird (zumindest von FreeBSD) beim Booten 
> geloescht, und wenn ein Stopskript alte PID-Files loescht, bleibt als 
> Fehlerquelle nur ein crash uebrig.
> 
> Dann laeuft kein Prozess mit dem Namen mehr, das laesst sich ja greppen.
> 
> Ein Neustart des Daemon wird in dem Fall ueber das herrenlose PID-File 
> meckern, da ist dann der Admin gefragt, bevor der Service wieder laeuft.
> 
> Wo war jetzt eigentlich das Problem? ;-)

Also, ich versuchs nochmal kurz:

Mein daemon macht open_log, fork, chown_log, drop_root, setsid, pidfile,
close(all_except_log). Oder so in der Art, müsste ich nachgucken.
Das ist ein Kontrollprozess. 

Der forkt sich dann pro Serviceprozess. Der macht dann irgendwas. Der
Kontrollprozess guckt nur, ob er Serviceprozesse nachforken muss, weil
plötzlich weg. Dann läuft das.

Nu möchte man neustarten. Normalerweise TERM an Kontroll, der macht
signal(SIGTERM, SIG_IGN) und TERM an die (also seine) Prozess-Session.
Dann nach 5 Sekunden macht er ein KILL an die ganze session. Das ist
also ganz einfach und direkt im signal handler implementiert (nicht
weils muss, sondern weils damals halt gereicht hat und er einen Modus
"kann", wo er keine Serviceprozesse hat sondern return'd - blöde Idee
damals gewesen, "compat" :)

Nu passierts (angeblich, irgendwie, keine Ahnung) dass er beim Neustart
merkt, dass die alte Session (laut PID file) noch lebt (also Kinder
hat), obwohl der Session leader (also der Prozess mit der PID aus dem
File) nicht mehr da ist. Wie auch immer das kommt.

Nu passierts auch, dass er merkt, dass selbst der Prozess noch lebt
(gut, läuft schon), aber manchmal ist das ein Fremder. 

Also macht das rcscript ein kill `cat $pidfile`, der Daemon findet
maximal ne session und macht die mit TERM + 5 sec + kill platt.

(Daran nervt mich eigentlich nur, dass sowas hin- und wieder passiert,
obwohl es nicht passieren sollte :-))

Das Problem ist dann auch noch, dass ich im signal handler (in prod.
version) nicht loggen kann, weils dann deadlocks gibt (wg.
multithreading logging, was gerade loggt während ein signal wie kill
kommt). Ohne logging sieht man dann natürlich wieder schonmal gar nix...

Schätze, für ne Analyse müsste ich zwei Tage einplanen: einmal was
analysierbares einbauen (z.B. memory mapped "score board" mit
Statistiken, low-level logging ohne libs, threads und nix, einfach nur
$pid.log mit write füllen oder sowas, ...) und dann halt sehen, ob und
wie ich das provoziert kriege. Also alles klar - bis auf die zwei Tage
lol :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.