Al Bogner, Donnerstag, 1. April 2004 13:07:
Am Donnerstag, 1. April 2004 01:05 schrieb Matthias Houdek:
Ich bestimme empirisch einen Grenzwert der CPU-Auslastung, ab wann der Server ohne erreichbare Clients runtergefahren werden darf.
Wenn es denn wirklich keine andere Möglichkeit gibt.
Ob von anderen Rechnern aus Prozesse ausgeführt werden sollte sich mit ps abchecken lassen.
Ich hatte mal erwähnt, dass Voraussetzung für das Runterfahren des Servers ist, dass _kein_ Client vom Server erreichbar ist. Spricht etwas dafür mit ps zu analysieren oder reicht nicht einfach ein erfolgloser ping?
Gut, wenn du ausschließen kannst, dass niemand auf dem Client in der Lage ist Pingantworten zu verhindern.
Sollten diese Tests negativ ausfallen (also keine Aktivität), könnte noch ein Countdown als Message an die Clients geschickt werden (vgl. Novell Netware).
Siehe oben. Da 1. Bedingung für das Runterfahren ist, dass kein Client erreichbar ist, kann ich dann an den Client auch nichts mehr versenden.
Ja, das ist dann logisch und damit hinfällig.
Das Script selber bestimmt mit top kurz hintereinander 3x die CPU-Auslastung und es wird ein Mittelwert errechnet. Dazu sende das Script einige Zeit Mails, wann geprüft wurde und was ermittelt wurde. Das ist probeweise mal für den P II 82 und für den XP2400 98.
Hm, das ist ziemlich vage. Wenn z.B. eine Datei über das Netz geöffnet ist, verursacht sie keine CPU-Aktivität.
Genau, das ist ja das Problem und darum auch dieses Posting. Es gibt einige Prozesse, die praktisch keine CPU-Aktivität-Erhöhung bewirken, speziell auf schnellen Rechnern. Die Auswertung von "running / sleeping" macht IMO auch keinen Sinn.
In der Praxis sieht das so aus, dass unterschiedliche User selten länger als bis 20h die 2 Server brauchen, es kann aber auch vorkommen, dass mal bis nach Mitternacht gearbeitet wird. Insofern scheidet eine fixe Zeit zum Runterfahren der Server (aus Stromspargründen) aus.
Die Server haben keine Monitore und so ohne weiteres kann man auf denen nicht direkt arbeiten. Es bleiben also die Situationen, wo die Server selbständig etwas tun. Es ist natürlich schwer an all die Prozesse zu denken, die besser nicht unterbrochen werden sollten. Ich habe mir mal als weiteres Kriterium überlegt, wenn der Server (dial-up) online ist, wird nicht runtergefahren, sondern gewartet.
Wieso? Wenn kein Client mehr im Netz ist (Ping-Test), wer soll dann noch eine Datei offen haben? Du musst dann also nur noch checken, ob evtl. ein von cron angeschubster Job läuft, den du nicht unterbrechen willst, und dann aus die Kiste. Und welche Jobs von cron angeworfen sein können, solltest du als Admin der Server schon wissen. *g*
Weiters wird bei allen eigenen Scripts, die per cronjob aufgerufen werden, gleich am Anfang geprüft, ob ein shutdown aktiv ist. So sollte es nun nicht mehr zur Situation kommen, dass das eine Script den Server gerade runterfährt, während das andere eine Internetverbindung aufbaut und zB Mails holt.
Sicherlich möglich, aber du hast eine kleine Sicherheitslücke zwischen dem Shutdown-Check im cronjob und dem Start des Shutdowns nach erfolgreichem Aktivitätscheck.
Du bist von der Voraussetzung ausgegangen, dass Clients aktiv sein können, die aber nicht zutrifft.
Nicht unbedingt, auch cron selbst könnte in diese Lücke reinschießen. Aber da sollte eine kleine Kunstpause im cronjob-Script nach dem Shutdown-Check schon ausreichen. Wenn der Server runtergefahren wird, werden keine neuen Prozesse mehr angeleiert.
Ich bin mir nicht sicher, wie problematisch es ist bzw. wo Zeitverzögerungen zu Problemen führen können.
Das "Ausschalt-Script" läuft in einer Schleife und prüft je nach Server alle 4 - 10 Minuten und hat beim Hochfahren des Servers ein Delay von 15 min.
Nehmen wir nun an, dass das Script erkannt hat, dass keine Clients mehr erreichbar sind, der Idle-CPU-Wert größer gleich dem vorgegebenem Wert ist und keine Online-Verbindung besteht.
Ich füge mal den Scriptteil ein, wie aktuell getestet wird:
if [ $RECHNERNAME = server ]; then ... IDLEWERT=$((( $IDLEWERT1 + $IDLEWERT2 + $IDLEWERT3 ) / 3 )) ONLINEOK=`/usr/sbin/cinternet-wwwrun --only-local -i ippp0 \ --status | grep status`
if [ "$ONLINEOK" = "status: lurking" -a $IDLEWERT -ge 82 ]; then echo "$RECHNERNAME wurde automatisch um `date +%H:%M:%S` \ heruntergefahren, da keine Clients aktiv sind, Idle $IDLEWERT - \ $ONLINEOK" \
| /usr/bin/mail -s "SHUTDOWN VON $RECHNERNAME UM \
`date +%H:%M:%S` - Idle $IDLEWERT - $ONLINEOK" $WARN shutdown -h +0 ...
Nach der Abfrage der 3 "IDLEWERTE" wird also noch der Online-Status abgefragt, d.h. wenn zeitgleich mit der Definition der Variable "ONLINEOK" ein Cronjob startet und der Rechner nicht online ist, dann wird dieser Cronjob durch shutdown abgewürgt.
Genau das meinte ich. Daher eine ausreichende Kunstpause im Cronjob, damit der noch keine Dateien offen haben kann, die evtl. leiden könnten.
Die kritischte Situation ist IMO das Abholen der emails. Und hier sollte IMO im Script, das die Mails abholt, greifen, dass nach einem shutdown abgefragt wird. Allerdings sind da wieder eine Kleinigkeit an Unsicherheiten dabei, nämlich die Bedingung und das lokale Versenden des emails vor dem Shutdown. Andererseis dauert das Aufbauen einer ISDN-Verbindung auch etwas Zeit, sodass ich im Extremfall hoffe, dass der Rechner dann bereits soweit runtergefahren ist, dass keine emails mehr empfangen werden können.
Ich denke, wenn er Online ist, soll er nicht runterfahren?
1. crond beenden (evtl. zwischenzeitlich gestartete Scripts laufen trotzdem weiter, neue werden nicht mehr gestartet)
Danke, das finde ich eine gute Idee.
2. (evtl. nach Ablauf des CountDowns) alle Netzwerk-Daemons (Apache, FTP-Server, ssh-Server, POP-Server, Samba, ...) beenden.
Ich denke, das ist vernachlässigbar, da einige Dienste davon nur intern laufen und Clients ja per Vorgabe nicht mehr aktiv sind.
Gut, dann kannst du dir das sparen. Aber schaden kann es auch nicht, es könnte ja sein, dass ein Windoser nur mal so rebootet ;-)
3. Noch einmal Prozess-Check (noch laufende cronjobs), bis keine Jobs mehr laufen, dann shutdown.
Geht das irgendwie allgemein oder muß man jeden theoretischen cronjob einzeln prüfen? Für den Fall, dass auf "man ps" verwiesen werden sollte, in "man ps" fand ich für eine allgemeiner Prüfung laufender cronjobs keine Lösung.
Mit dem Parameter "j" steht in der ersten Spalte der Ausgabe von ps die PID des aufrufenden Prozesses (PPID). Du brauchst also nur: ps -A j | grep -e ^$CRONPID auszuwerten, ob da Zeilen zurückgegeben werden. Die PID von cron kannst du einfach aus /var/run/crond.pid auslesen. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu