Probleme mit fork???

[funnydingo]

Hallo zusammen,

ich habe ein extrem blödes Problem auf meinem Server (SuSE 8.1) und ich bekomme es nicht gefixt.

Wenn sich jemand via SSH einloggen will fliegt er raus bekommt jedoch eine Meldung die sich auch im /var/log/messages wieder findet

Aug 9 16:21:43 pxxxxxxxx sshd[31926]: Accepted password for xxx from 217.80.252.159 port 12773
Aug 9 16:21:43 pxxxxxxxx sshd[31928]: Disconnecting: fork failed: Resource temporarily unavailable

Logge ich mich mit root ein (was perfekt funktioniert) und mache nen SU, dann fliege ich aus der Session raus und habe im Log stehen:

Aug 9 16:25:12 pxxxxxxxx su: pam_unix2: session started for user xxx, service su
Aug 10 16:25:12 pxxxxxxxx su: pam_unix2: session finished for user xxx, service su

Das besondere: Es sind nicht alle User betroffen! Mit manchen Accounts kann man ohne Probleme arbeiten und andere machen Probleme.

Kann mir jemand sagen was ich da für ein Problem habe???

Gruß,


-Funny-

[captaincrunch]

Ganz spontan würde ich sagen, dass du zu viele gleichzeitige Files im System offen hast.

Was sagt ein cat /proc/sys/fs/file-max ? Du könntest mal versuchen, per
echo ZAHLDIEHÃ?HERISTALSDASWASEBENRAUSKAM > /proc/sys/fs/file-max
diesen Wert zu erhöhen, und ich möchte behaupten, dass das Problem dann nicht mehr auftritt.

[funnydingo]

Also ich bekomme nen Wert von 25388 ausgegeben? Meinst echt das dies zu viel ist? Wenn das wirklich der Fall sein sollte, gibt es einen Weg wie ich mir anzeigen lassen kann, welche Anwednung wie viele Files offen hat? In dem Fall würde es mich interessieren wer der Urheber ist.

[alexander newald]

Wenn er zuviele offene Dateien hätte, würde es bei allen nicht mehr gehen.

Hast du irgendwo per ulimit oder pam die max. Anzahl der Tasks begrenzt, die der Benutzer ausführen darf?

Wieviele Tasks laufen von dem Benutzer, bei dem man rausgeschmissen wird?

Wie sieht die .profile .bash_login der Benutzer aus?

[captaincrunch]

Wenn er zuviele offene Dateien hätte, würde es bei allen nicht mehr gehen.

Nicht zwangsläufig, da die Anzahl der offenen Files ziemlich schnell variieren kann. Trotz allem sind deine Ideen auch alles andere als abwegig ... ;)

[dea]

Ich würde auch eher in Richtung User-spezifische Resource-Limits nachsehen. limits.conf und Konsorten (bei Debian unter /et/security) sowie ggf. auch mal die Quotas checken. Der Hinweis auf die .profile und .bash* ist auch sinnvoll, wie ist denn Dein Indianer und PHP (cgi) eingerichtet?

[funnydingo]

Also,

ulimits sind keine gesetzt. Ich habe auch keine Beschränkungen in der /etc/security/limits.conf eingetragen. Die Einschränlungen via PAM hören sich nach ganz interessant an, nur weiß ich nicht wie ich prüfen kann ob/welche gesetzt sind.

Der Apache selbst läuft mit dem von SuSE vorgegeben User wwwrun und der Gruppe www. Der User wwwrun unterliegt diesem Problem aber nicht. Es gibt aber einen User der bei einigen vhosts als User angegeben ist und diesem Problem unterliegt. Die letzte Ã?nderung am Apache war jedoch am 02.08.2003. An diesem Tag habe ich Apache mit SSL neuinstalliert. Das Problem habe ich jedoch das erste mal am 08.08 und wieder am 10.08 gehabt. Ich denke der Zeitraum zwischen der Neuinstallation und dem ersten Auftreten ist viel größer als vom ersten zum zweiten Auftreten.

Ich finde das sehr merkwürdig.

[olaf.dietsche]

Wenn sich jemand via SSH einloggen will fliegt er raus bekommt jedoch eine Meldung die sich auch im /var/log/messages wieder findet

Aug 9 16:21:43 pxxxxxxxx sshd[31926]: Accepted password for xxx from 217.80.252.159 port 12773
Aug 9 16:21:43 pxxxxxxxx sshd[31928]: Disconnecting: fork failed: Resource temporarily unavailable

Das heißt, du hast bereits die maximale Anzahl an Prozessen laufen. Wenn jemand versucht sich anzumelden, dann muß eine neue bash gestartet (fork+exec) werden. Da die Prozesstabelle schon voll ist, geht das nicht. Sobald sich ein Prozess beendet, ist ein Eintrag in der Tabelle frei und der Login könnte funktionieren.

Entweder hast du insgesamt zu viele Dienste laufen oder irgendein Prozess läuft Amok und startet ständig neue Kinder. Sieh mal nach was

Code: Select all

pstree

liefert.

[funnydingo]

Ich glaube es ist doch der Apache!

Code: Select all

init-+-atd
     |-httpd-+-2*[httpd---37*[topsites.cgi]]
     |       |-httpd---44*[topsites.cgi]
     |       |-httpd---42*[topsites.cgi]
     |       |-httpd-+-41*[topsites.cgi]
     |       |       `-2*[topsites_en.cgi]
     |       |-httpd-+-37*[topsites.cgi]
     |       |       `-topsites_en.cgi
     |       |-httpd---39*[topsites.cgi]
     |       |-httpd---26*[topsites.cgi]
     |       |-httpd---23*[topsites.cgi]
     |       |-httpd---32*[topsites.cgi]
     |       |-httpd-+-18*[topsites.cgi]
     |       |       `-topsites_en.cgi
     |       |-httpd-+-22*[topsites.cgi]
     |       |       `-topsites_en.cgi
     |       |-httpd---8*[topsites.cgi]
     |       |-httpd---7*[topsites.cgi]
     |       |-2*[httpd---2*[topsites.cgi]]
     |       |-2*[httpd---3*[topsites.cgi]]
     |       |-3*[httpd---topsites.cgi]
     |       `-28*[httpd]

Das sieht nicht ganz richtig aus. Ich habe den Apache dann mal neugestartet und 5 Minuten später siehts so aus:

Code: Select all

init-+-atd
     |-httpd-+-25*[httpd]
     |       |-2*[httpd---2*[topsites.cgi]]
     |       |-6*[httpd---topsites.cgi]
     |       |-3*[httpd---3*[topsites.cgi]]
     |       `-httpd---5*[topsites.cgi]

Dabei ist das Perl-Script "topsites.cgi" nicht so ein komplexes Script.

[darkspirit]

Aber wohl eins, dass sich in einer Schleife verabschiedet.. ;) wenns nicht zu lang ist, poste das doch mal hier.

[funnydingo]

Das ist ein wenig zu lang ;-)

Aber ganz ehrlich, ich glaube nicht das es das Script ist, da ich dieses schon seit fast einem Jahr nutze und diese Problem erst seit ein paar Tagen existiert. Ich habe auch "nur" von Apache 1.3.27 auf 1.3.28 updated und SSL hinzugefügt. Ich kann mir nich vorstellen das dies solche Probleme auf das Perl-Script hat, oder???

Wenn ich einen "ps ax | grep topsite.cgi" mache, bekomme ich eine entsprechend lange Liste mit Prozessen die aber alle "<defunct>" sind. Was genau bedeutet dieses "<defunct>" denn? Meines wissens nach ist das ein Prozess der eigentlich zu ende ist, aber nicht korrekt beendet werden konnte und als "Zombie" läuft? Das würde auch zur Ausgabe von "top" passen, der mit sagt:

Code: Select all

399 processes: 120 sleeping, 7 running, 272 zombie, 0 stopped

Also das gefällt mir gar nicht!

[olaf.dietsche]

Ein Zombie ist ein Prozess, der zwar beendet ist, aber dessen Elternprozess den Exitstatus noch nicht abgefragt hat. Solange ein Zombie existiert, verbraucht er zwar keine CPU und Hauptspeicher, aber er belegt einen Platz in der Prozesstabelle. Das wiederum erklärt deine Probleme mit fork.

[funnydingo]

Wer ist den im Falle eines CGI's der Parent? Der Apache? Perl? Ich habe zum Test mein sehr kleines Perl-Script geschrieben:

Code: Select all

#!/usr/bin/perl

print "Conetent-type: text/htmlnn";
for($i=0; $i>10000; $i++) {
  print "Durchlauf " .($i + 1) . "<br>n";
}

Dieses Script habe ich dann mal von diversen Clients x-mal aufrufen lassen. Alles arbeitet völlig normal. Ich sehe doe Prozesse während der Abarbeitung und sie werden danach korrekt beendet. Für mich führt es dazu: Das "topsite.cgi" selbst schein ein Problem zu haben. Aber dann frage ich mich: Warum lief es ein Jahr ohne Probleme und macht nun Stress?

Dann ist mir gerade noch was aufgefallen. Ich habe hier im Forum ab und zu mal was von "strace" gehört und habe einfach mal "strace -p PID_EINES_ZOMBIES" augerufen. Folgende Ausgabe bekomme ich:

Code: Select all

attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

Hat das was zu sage oder bekomme ich die Ausgabe nur, gerade weil das ein Zombie ist?

[captaincrunch]

Wer ist den im Falle eines CGI's der Parent? Der Apache? Perl?

Wie du im pstree recht schön erkennen kannst der Apache.

Für mich führt es dazu: Das "topsite.cgi" selbst schein ein Problem zu haben. Aber dann frage ich mich: Warum lief es ein Jahr ohne Probleme und macht nun Stress?

Gute Frage. Ein Anhaltspunkt könnte der neue Apache sein. Hast du sonst seitdem noch etwas am System verändert ?

Hat das was zu sage oder bekomme ich die Ausgabe nur, gerade weil das ein Zombie ist?

Sieht fast so aus, als würde der ptrace-Aufruf geblockt. Hast du einen aktuellen, ptrace-buggefixten Kernel ?

[funnydingo]

Ui, frag mich was leichteres. Hab die SuSE 8.1 von 1&1 drauf. Ich meine des is der 2.4.20!? Ich bin auch ganz ehrlich: ich wüsste nicht wie ich des am besten nachsehen kann. Dachte ich schaue einfach mal unter /lib/modules nach, aber dort findet sich 2.4.19 und 2.4.20, aber wenn das ich mal gelernt habe stimmt, kann ja nur ein Kernel davon laufen, ODER?

Achso, und im Bezug auf Ã?nderungen am System: Nein, ich habe nur ein Update des Apache vorgenommen (und mod_ssl hinzugefügt, was vorher fehlte). Alle anderen Ã?nderungen liegen schon einige Monate zurück.

[captaincrunch]

So ist es. Nachschauen kannst das das am einfachsten per uname -a

Eine weitere Möglichkeit wäre cat /proc/version (kommt aber auf's gleiche raus wie das o.g. Kommando)

[funnydingo]

Ah, ja, das sieht doch nach einer sehr brauchbaren Informaion aus. Es ist der 2.4.20.

[captaincrunch]

Hmm, wobei ich mich jetzt nicht am strace festbeißen würde, was ohnehin nicht viel bringen würde, selbst wenn's klappen würde, da ein Zombie ohnehin nichts macht, außer die Prozesstabelle zu belagern.

Schieß doch erstmal sämtliche Zombies ab, am einfachsten per Shell-Einzeiler :

Code: Select all

kill -9 `ps aux | grep defunct | awk '{ print $2 }'`

Sofern die erstmal weg sind, kannst du erstmal weiter beobachten, ob sich die Zombies mit der Zeit wieder erhöhen. Falls ja, kannst du weiter auf Fehlersuche gehen.

[funnydingo]

Das tun sie. Ich kill die Zombies ja zwischen durch (bisher mit nem restart des Apache, aber dein Einzeiler gefällt mir besser ;-)) Dann muss ich wohl oder über mal das Script durchgehen. Ich danke aber trotzdem allen die mir bisher geholfen haben ;-)