Was machst Du denn, wenn der Server down ist? Kann man das eventell in ein Script packen, oder mußt Du per iLo den Power-Knopf drücken?

Grüße
Malte

Ich gehe per SSH (wie weiter oben schon beschrieben) auf den Server und führe einen Reboot durch ....

Ich denke, dass sich nur der Indianer verabschiedet, da der Rest ja weiter funktioniert, aber nichts genaues weiss ich nicht ....

Wie gesagt, das ist Christians Kind, und ich denke auch das er sich bald kümmern wird....

viele Grüße
Pierre

PS: Indianer = Apache

Wieso versucht er, eine 2GB-Datei zu schreiben? In welchem Kontext? Weshalb kann/darf er das nicht? Dateisystem?
Könnte man mir da mal etwas Code zukommen lassen?

mfG
Markus

Nachtrag: Wäre es da nicht sinnvoll, nen kleinen Watchdog zu Coden, der auf einen Denial of Service prüft? Einfach alle 5 min eine Anfrage an den Indianer schicken und sehen, was passiert!

Geändert von MarkusJ am 25. April 2007 um 18:58

Ich nix Code haben ... ich nix Ahnung davon ... ich nur Admin zur Pflege, Backup und Reboot ....

Ja, iwie kann das Dateisystem solche großen Daten nicht verarbeiten....

Greetz
Pierre

Was fürn System issen das? Und bei der Gelegenheit: Welche Dateien werden so groß? Logs? Die Datenbank (müsste das doch eigentlich selber erledigen)?
Evtl. würde sich ja ein Dateisystemwechsel anbieten ...

mfG
Markus

Zitat:

---

Original geschrieben von MarkusJ
Was fürn System issen das? Und bei der Gelegenheit: Welche Dateien werden so groß? Logs? Die Datenbank (müsste das doch eigentlich selber erledigen)?
Evtl. würde sich ja ein Dateisystemwechsel anbieten ...

---

Netcraft sagt, es sei ein Debian, und es plaudert auch aus, dass ihr einen Apache 2.0.54 habt, das Subversion für die Versionskontrolle der Software offensichtlich auch noch auf dem gleichen Server mitläuft und ihr den Tomcat über mod_jk2 angehängt habt. Alles Ok, aus meiner Sicht. Aber: wenn ihr einen 2GB Limit habt, dann hat ihr vermutlich entweder einen alten Kernel oder ein altes Filesystem (evtl Reiser?). Ein ext3 kann problemlos Files länger als 2GB verarbeiten, es sei denn man hätte einen älteren 32bit Kernel. Auf meinem schon ziemlich betagten SuSE 9.0 (Kernel 2.4.21, etwas älteres habe ich nicht mehr) kann ich mit java.io.FileWriter auch ein 5GB File schreiben, es ist also auch kaum eine Java-Limite.

Falls die Software ihre Logs mit log4j schreibt, könnte man über die MaxFileSize Option des RollingFileAppender verhindern, dass je eine Logfile grösser als 1GB wird, das müsste eigentlich reichen.

Zitat:

---

Ich denke, dass sich nur der Indianer verabschiedet, da der Rest ja weiter funktioniert, aber nichts genaues weiss ich nicht ....

---

Nach meiner Erfahrung ist es vor allem der Tomcat (zwar auch ein Apache-Projekt), der gelegentlich diese Art von Schwierigkeiten macht, nicht der Apache (der "Eigentliche").

Jupp, tomcat hängt sich bei uns auch hin und wieder auf. Alle Java-Instanzen killen und die Software neustarten hilft da meist. (Reboot ist eigentlich nie nötig)

2GB-Grenze bei logdateien glaube ich eigentlich eher nicht. Bevor 2GB voll sind, müssen schon etliche Millionen Requests reinlaufen.

Wie wäre es mit einem Cronjob, der die Kiste morgens um 5 oder so rebootet?!

Besser regelmäßig 'ne kleine Auszeit wenn es kaum einen (jens?) stört, als unregelmäßig eine lange, wenn es viele stört!

Grüße
Malte

Zitat:

---

Original geschrieben von hybrid
2GB-Grenze bei logdateien glaube ich eigentlich eher nicht. Bevor 2GB voll sind, müssen schon etliche Millionen Requests reinlaufen.

---

Kommt ganz darauf an, was Du loggst. Mir kommt da so eine kleine Anwendung in den Sinn, die ich vor einigen Jahren mal verbrochen habe, welche ein ziemlich ausführliches Log schreiben kann (man kann's auch abstellen), da kommt leicht ein GB pro Tag zusammen.

Zitat:

---

Wie wäre es mit einem Cronjob, der die Kiste morgens um 5 oder so rebootet?!

---

Finde ich nicht so gut, wenn schon den tomcat per cron stoppen und neu starten.

In vielen Fällen, bei denen ich dieses Verhalten beobachtet habe, war ein Memory-Leak in der Anwendung dafür verantwortlich. Ja, das gibt es auch in Java, wenn man Referenzen auf Objekte nicht wegräumt. Die Gefahr in einem Webcontainer ist, dass man Objektreferenzen an eine Benutzersession hängt, die lange Lebensdauer hat. Alle diese Objekte werden erst weggeräumt wenn die Session terminiert wird, sofern dies überhaupt geschieht. Vielleicht würde es sich lohnen, regelmässig sar laufen zu lassen, damit könnte man diese bestätigen oder widerlegen.

Klar, wenn es reicht, dem Tomcat einen zu verplätten: Super.
Momentan hängt der Webserver z.T. ein paar Stunden und Pierre macht nen harten Reboot. da wären 2Minuten Boot-Zeit pro Tag nicht die Welt...

Wie es Java bei dieser lausigen Stabilität selbst in den "Enterprise"-Unternehmenseinsatz geschafft hat, ist mir absolut schleierhaft...

Grüße
Malte

PS: Bei einem Webserver werden gewöhnlich die Requests und die Fehler geloggt. Fehler passieren selten, kann man ignorieren... Wenn man 100Bytes Logdaten pro request annimt, wären 2GB ca 20Mio Requests. Das braucht hier schon ein paar Wochen... Vielleicht loggt das Ding aber schon seit Monaten mit höchster Verbosity, dann hätte sich aber jemand heftig verkonfiguriert

Geändert von hybrid am 26. April 2007 um 13:39

Ich kann mir nicht vorstellen das es an einem Logfile liegt. Systemlogs oder Apache Logs haben normal ein Logrotate also wird ein Logfile nicht so groß.

Ich hätte auch mal vermutet das es am Tomcat liegt. Hab das Teil einmal installiert und nie wieder. OHHHHH WIE ICH JAVA HASSE!!

"/etc/init.d/tomcat restart" kannst mal versuchen statt neu starten.