Es geht darum, dass ein Server abends automatisch runterfahren soll, wenn alle Clients down sind und der Server selber im Leerlauf ist. Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt, sondern max. ca. 93%, meist 90%. Unter welchen Voraussetzungen kann ich den Rechner gefahrlos runterfahren, ohne, dass irgendein cronjob, etc. unterbrochen wird? Ob ein Client aktiv ist, prüfe ich mit ping und ob eine Onlineverbindung besteht mit cinternet-wwwrun. Es ist keine gute Lösung meines Problems, den Server zu einer bestimmten Zeit runterzufahren. Al
Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt, sondern max. ca. 93%, meist 90%. Unter welchen Voraussetzungen kann
Was läuft denn da und verbraucht so viel? Mein P-II-350 hat ungefähr ein Prozent Leerverbrauch und da ist schon der Overhead von den mehreren NFS- und Samba-mounts drin sowie den ständigen IMAP-clients apache, imap, nfs, samba, postgresql, mysql, inn, bind laufen da u.a. Bernd
Am Dienstag, 30. März 2004 18:58 schrieb Bernd Laengerich:
Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt, sondern max. ca. 93%, meist 90%. Unter welchen Voraussetzungen kann
Was läuft denn da und verbraucht so viel?
Wenn du mir verrätst wie ich die top-Ausgabe in eine Datei umleite, dann poste ich das. Ich finde es leide nicht mehr heraus wie das ging. Die CPU-Anzeige der Prozesse liegt überall unter 1%, meist 0,0%, manchmal 0,5%. Oben steht aber 90% idle. Top wurde als root ausgeführt und es läuft 2.4.24-grsec Al
On Tue, Mar 30, 2004 at 06:36:21PM +0200, Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt,
logisch. top braucht natuerlich auch rechenleistung. Stell mal das AkutalisierungsIntervall hoch ( Taste 's' oder '-d ss.tt' [top 3.2.0]), dann sollte sich die Zahl aendern.
cronjob, etc. unterbrochen wird?
Ein cronjob sollte natuerlich so geschrieben sein, das es ihm egal ist. -- Have fun, Peter
Am Dienstag, 30. März 2004 20:01 schrieb Peter Wiersig:
On Tue, Mar 30, 2004 at 06:36:21PM +0200, Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt,
logisch. top braucht natuerlich auch rechenleistung. Stell mal das AkutalisierungsIntervall hoch ( Taste 's' oder '-d ss.tt' [top 3.2.0]), dann sollte sich die Zahl aendern.
Die verbrauchte Rechnerleistung von top entspricht aber keinesfalls 10%.
cronjob, etc. unterbrochen wird?
Ein cronjob sollte natuerlich so geschrieben sein, das es ihm egal ist.
Ich weiß nicht, was passiert, wenn fetchmail oder die email-Weiterleitung über postfix mit spamassassin und amavis unterbrochen wird. Es sollten keinesfalls Mails verloren werden. Natürlich könnte ich speziell diese Prozesse prüfen, ich würde es aber gerne allgemeiner halten. top - 23:10:01 up 11:04, 2 users, load average: 0.05, 0.11, 0.14 Tasks: 55 total, 1 running, 54 sleeping, 0 stopped, 0 zombie Cpu(s): 6.3% user, 1.0% system, 0.0% nice, 92.7% idle Mem: 191204k total, 143664k used, 47540k free, 31080k buffers Swap: 133016k total, 14352k used, 118664k free, 54728k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command 2178 root 10 0 864 864 688 R 0.7 0.5 0:00.22 top 1 root 8 0 248 248 208 S 0.0 0.1 0:04.55 init 2 root 9 0 0 0 0 S 0.0 0.0 0:00.18 keventd 3 root 9 0 0 0 0 S 0.0 0.0 0:00.00 kapmd 4 root 18 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd_CPU0 5 root 9 0 0 0 0 S 0.0 0.0 0:03.11 kswapd 6 root 9 0 0 0 0 S 0.0 0.0 0:00.00 bdflush 7 root 9 0 0 0 0 S 0.0 0.0 0:00.00 kupdated 8 root 9 0 0 0 0 S 0.0 0.0 0:00.00 khubd 10 root 9 0 0 0 0 S 0.0 0.0 0:01.12 kjournald 16280 root 9 0 0 0 0 S 0.0 0.0 0:00.02 kjournald 23104 root 9 0 0 0 0 S 0.0 0.0 0:00.01 kjournald 10932 root 9 0 0 0 0 S 0.0 0.0 0:03.04 kjournald 4351 root 9 0 1400 1396 896 S 0.0 0.7 0:02.87 isdnlog 3876 root 8 0 1068 736 580 S 0.0 0.4 0:00.26 ipppd 29697 root 9 0 600 600 504 S 0.0 0.3 0:04.84 syslogd 22184 root 9 0 1492 1492 428 S 0.0 0.8 0:01.89 klogd 17023 root 0 0 1436 1324 1224 S 0.0 0.7 0:01.16 smpppd 29296 root 9 0 452 432 388 S 0.0 0.2 0:00.00 resmgrd 27643 bin 9 0 372 364 304 S 0.0 0.2 0:00.00 portmap 5013 root 9 0 4576 2968 1768 S 0.0 1.6 0:00.03 miniserv.pl 19907 lp 9 0 856 804 712 S 0.0 0.4 0:00.04 lpd 11204 named 9 0 2696 2612 1964 S 0.0 1.4 0:00.01 named 1938 named 9 0 2696 2612 1964 S 0.0 1.4 0:00.01 named 12088 named 9 0 2696 2612 1964 S 0.0 1.4 0:02.90 named 31950 named 9 0 2696 2612 1964 S 0.0 1.4 0:00.04 named 7919 named 9 0 2696 2612 1964 S 0.0 1.4 0:00.36 named 24134 root 9 0 1368 1252 1144 S 0.0 0.7 0:01.52 sshd 16893 root 8 0 20532 11m 2196 S 0.0 6.0 0:04.75 spamd 32670 root 8 0 1252 1060 988 S 0.0 0.6 0:02.19 master 29341 postfix 9 0 1336 1176 1000 S 0.0 0.6 0:02.48 qmgr 29332 root 8 0 856 756 684 S 0.0 0.4 0:00.13 xinetd 26689 at 9 0 568 532 496 S 0.0 0.3 0:00.00 atd 26317 root 8 0 676 656 604 S 0.0 0.3 0:00.05 cron 14921 root 9 0 724 692 600 S 0.0 0.4 0:01.35 nscd 25494 root 9 0 724 692 600 S 0.0 0.4 0:00.00 nscd 11825 root 9 0 724 692 600 S 0.0 0.4 0:00.09 nscd 30378 root 9 0 724 692 600 S 0.0 0.4 0:00.11 nscd 16225 root 9 0 724 692 600 S 0.0 0.4 0:00.26 nscd 1177 root 9 0 724 692 600 S 0.0 0.4 0:00.17 nscd 13669 root 9 0 724 692 600 S 0.0 0.4 0:00.05 nscd 20636 root 9 0 488 464 464 S 0.0 0.2 0:00.21 mingetty 11384 root 9 0 472 408 408 S 0.0 0.2 0:00.05 mingetty 29810 root 9 0 468 408 408 S 0.0 0.2 0:00.06 mingetty 31469 root 9 0 472 408 408 S 0.0 0.2 0:00.06 mingetty 22360 root 9 0 472 408 408 S 0.0 0.2 0:00.08 mingetty 10128 root 9 0 468 408 408 S 0.0 0.2 0:00.06 mingetty 6745 root 9 0 1112 832 832 S 0.0 0.4 0:00.01 squid 19427 squid 9 0 6016 4420 1508 S 0.0 2.3 0:03.81 squid 9803 squid 9 0 268 252 224 S 0.0 0.1 0:00.04 unlinkd 18421 postfix 9 0 1188 1188 956 S 0.0 0.6 0:00.01 pickup 32203 root 9 0 2124 2060 1748 S 0.0 1.1 0:00.38 sshd 27471 root 9 0 1696 1696 1248 S 0.0 0.9 0:00.15 bash 758 root 9 0 2088 2024 1748 S 0.0 1.1 0:00.23 sshd 7493 root 8 0 1668 1668 1228 S 0.0 0.9 0:00.09 bash Wenn ich mir das so ansehe, dann hat top 0.7% CPU bei 92.7% idle. Wo ist die Differenz? Al
Am Dienstag, 30. März 2004 23:14 schrieb Al Bogner:
Am Dienstag, 30. März 2004 20:01 schrieb Peter Wiersig:
On Tue, Mar 30, 2004 at 06:36:21PM +0200, Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt,
logisch. top braucht natuerlich auch rechenleistung. Stell mal das AkutalisierungsIntervall hoch ( Taste 's' oder '-d ss.tt' [top 3.2.0]), dann sollte sich die Zahl aendern.
Die verbrauchte Rechnerleistung von top entspricht aber keinesfalls 10%.
cronjob, etc. unterbrochen wird?
Ein cronjob sollte natuerlich so geschrieben sein, das es ihm egal ist.
Ich weiß nicht, was passiert, wenn fetchmail oder die email-Weiterleitung über postfix mit spamassassin und amavis unterbrochen wird. Es sollten keinesfalls Mails verloren werden.
Ich denke, ich habe eine brauchbare Lösung gefunden. Wenn jemand eine bessere Idee hat, bitte posten. Ich bestimme empirisch einen Grenzwert der CPU-Auslastung, ab wann der Server ohne erreichbare Clients runtergefahren werden darf. 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. 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. Al
Al Bogner, Donnerstag, 1. April 2004 00:05:
Am Dienstag, 30. März 2004 23:14 schrieb Al Bogner:
Am Dienstag, 30. März 2004 20:01 schrieb Peter Wiersig:
On Tue, Mar 30, 2004 at 06:36:21PM +0200, Al Bogner wrote:
Das Problem dabei ist, dass der P II nie 100% idle mit top anzeigt,
logisch. top braucht natuerlich auch rechenleistung. Stell mal das AkutalisierungsIntervall hoch ( Taste 's' oder '-d ss.tt' [top 3.2.0]), dann sollte sich die Zahl aendern.
Die verbrauchte Rechnerleistung von top entspricht aber keinesfalls 10%.
cronjob, etc. unterbrochen wird?
Ein cronjob sollte natuerlich so geschrieben sein, das es ihm egal ist.
Ich weiß nicht, was passiert, wenn fetchmail oder die email-Weiterleitung über postfix mit spamassassin und amavis unterbrochen wird. Es sollten keinesfalls Mails verloren werden.
Ich denke, ich habe eine brauchbare Lösung gefunden. Wenn jemand eine bessere Idee hat, bitte posten.
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. Netzwerktraffic aus dem lokalen Netz lässt sich ebenfalls analysieren. smbstatus liefert die Infos über geöffnete Dateien über Samba, NFS sollte ähnliches zu bieten haben. Sollten diese Tests negativ ausfallen (also keine Aktivität), könnte noch ein Countdown als Message an die Clients geschickt werden (vgl. Novell Netware).
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.
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. Würde ich erweitern: Aktivitätscheck (Siehe oben), dann evtl. Message an die Clients, dann Shutdown-Mechanismus nach folgendem Muster: 1. crond beenden (evtl. zwischenzeitlich gestartete Scripts laufen trotzdem weiter, neue werden nicht mehr gestartet) 2. (evtl. nach Ablauf des CountDowns) alle Netzwerk-Daemons (Apache, FTP-Server, ssh-Server, POP-Server, Samba, ...) beenden. 3. Noch einmal Prozess-Check (noch laufende cronjobs), bis keine Jobs mehr laufen, dann shutdown. -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
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?
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.
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.
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. 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. 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.
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.
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. Al
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
Am Donnerstag, 1. April 2004 20:22 schrieb Matthias Houdek:
Al Bogner, Donnerstag, 1. April 2004 13:07:
Am Donnerstag, 1. April 2004 01:05 schrieb Matthias Houdek:
Gut, wenn du ausschließen kannst, dass niemand auf dem Client in der Lage ist Pingantworten zu verhindern.
Ja, und wenn, selber schuld, dann gibt es keinen Zugriff mehr auf den Server :-) Im Ernst, die Nutzer sind überschaubar, haben physischen Zugang zum Server, aber kein root-PW und werden sicher keinen Unfug treiben.
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.
Genau das meinte ich. Ein User von einem client kann nicht mehr im Internet sein, aber zB fetchmail via cronjob und für diesen Fall wird gewartet.
Und welche Jobs von cron angeworfen sein können, solltest du als Admin der Server schon wissen. *g*
Klar, nachdem aber User am Server auf _ihrem_ Account per ssh cronjobs einrichten können, fetchmail läuft zB als user, kann ich da den Überblick verlieren bzw. das zu spät merken. Andererseits wird ohne meine Rückfrage kaum etwas verändert.
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.
Das habe ich mir mittlerweile auch überlegt. Denkst du, dass 5 Sekunden Pause reichen sollten?
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?
Mit der "Kunstpause" hat sich das Problem erledigt. Ich dachte an die Situation, dass der Rechner offline ist, zum Shutdown ansetzt und im selben Augenblick der cronjob online geht. Zu diesem Zeitpunkt dachte ich auch noch nicht den crond zu stoppen.
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 ;-)
Die Gefahr sehe ich weniger, schon eher das Problem, dass von einem User Linux rebootet wird (warum auch immer), doch das ist dann eben Pech, dass nur mehr 1 Client an ist und der Reboot genau in die Zeit fällt, sodass sich der Server ausschaltet. Der User kennt ja den Knopf zum Server hochfahren. Hauptzweck ist, dass nachts die Server automatisch runtergefahren werden. Im SmallOffice-Bereich macht es IMO keinen Sinn die Server 24h laufen zu lassen. Der erste User am Morgen schaltet die Server ein, nur das Runterfahren soll automatisch erledigt werden. Man kann ja nie an alles denken, aber ich vermute mal die einzige kritische Situation ist der Cronjob zum Abholen der Mails, die anderen Dinge sind reparierbar. Ich habe mal den Rechner runtergefahren, wo fetchmail zwar fertig war, spamassassin und amavis aber nicht, und ich denke es gingen keine Mails verloren, aber diese Situation soll verhindert werden.
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.
Danke. Al
Al Bogner <suse-linux@ml04q1.pinguin.uni.cc> writes:
Genau das meinte ich. Ein User von einem client kann nicht mehr im Internet sein, aber zB fetchmail via cronjob und für diesen Fall wird gewartet.
Du muß da nicht päpstlicher sein als der Papst. Auch cron und fetchmail bekommen i.d.R. ein ordentliches SIGTERM beim shutdown. Da geht nichts verloren und es ist kein Weltuntergang, wenn cron mal bei seiner Arbeit unterbrochen wird. Oder kommt cron aus Redmond? ;-) Martin
Am Donnerstag, 1. April 2004 23:56 schrieb Martin Schmitz:
Al Bogner <suse-linux@ml04q1.pinguin.uni.cc> writes:
Genau das meinte ich. Ein User von einem client kann nicht mehr im Internet sein, aber zB fetchmail via cronjob und für diesen Fall wird gewartet.
Du muß da nicht päpstlicher sein als der Papst. Auch cron und fetchmail bekommen i.d.R. ein ordentliches SIGTERM beim shutdown. Da geht nichts verloren und es ist kein Weltuntergang, wenn cron mal bei seiner Arbeit unterbrochen wird. Oder kommt cron aus Redmond? ;-)
Schön das zu hören. Das hoffe ich ja auch, aber ich möchte nicht für Datenverlust verantwortlich sein, weil ich mir die Sache zu wenig überlegt habe. Die Wahrscheinlichkeit, dass diese Situation eintritt, die Probleme machen könnte, ist ja sowieso sehr gering, aber ich habe sie lieber hier durchdiskutiert. Al
Hallo, Am Thu, 01 Apr 2004, Al Bogner schrieb:
ps -A j | grep -e ^$CRONPID
Hm. Bei mir wird die Spalte PPID rechtsbuendig ausgegeben, da klappt das nicht mit dem grep...
auszuwerten, ob da Zeilen zurückgegeben werden. Die PID von cron kannst du einfach aus /var/run/crond.pid auslesen.
Danke.
Denk dran: erst PID auslesen, dann crond beenden! Sonst gibt's nen /var/run/cron.pid: No such file or directory :) Also z.B: ==== #! /bin/bash CRONPIDFILE="/var/run/cron.pid"; if test -r "$CRONPIDFILE" then CRONPID=$(<$CRONPIDFILE); else echo "cannot read $CRONPIDFILE" >&2 # wie Fehler behandeln?? fi /usr/sbin/rccron stop ps -A j | grep -e "^ *$CRONPID " # oder: ps -A j | awk "\$1 == $CRONPID { print; p++; } END{exit(p==0);}" ==== HTH, -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
David Haller, Freitag, 2. April 2004 00:20:
Hallo,
Am Thu, 01 Apr 2004, Al Bogner schrieb:
ps -A j | grep -e "^$CRONPID"
[schummel ;-)]
Hm. Bei mir wird die Spalte PPID rechtsbuendig ausgegeben, da klappt das nicht mit dem grep...
Hab ich vorher nicht geschrieben, dass $CRONPID auf 5 Stellen rechtsbündig mit ggf. führenden Leerzeichen formatiert werden muss? *g*
auszuwerten, ob da Zeilen zurückgegeben werden. Die PID von cron kannst du einfach aus /var/run/crond.pid auslesen.
Danke.
Denk dran: erst PID auslesen, dann crond beenden! Sonst gibt's nen
/var/run/cron.pid: No such file or directory
:)
Also z.B:
==== #! /bin/bash CRONPIDFILE="/var/run/cron.pid";
if test -r "$CRONPIDFILE" then CRONPID=$(<$CRONPIDFILE); else echo "cannot read $CRONPIDFILE" >&2 # wie Fehler behandeln?? fi
/usr/sbin/rccron stop
ps -A j | grep -e "^ *$CRONPID " # oder: ps -A j | awk "\$1 == $CRONPID { print; p++; } \ END{exit(p==0);}" ====
Ist awk hier nicht ein wenig überzogen? -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu
Hallo, Am Fri, 02 Apr 2004, Matthias Houdek schrieb:
David Haller, Freitag, 2. April 2004 00:20: [..]
ps -A j | grep -e "^ *$CRONPID " # oder: ps -A j | awk "\$1 == $CRONPID { print; p++; } \ END{exit(p==0);}" ====
Ist awk hier nicht ein wenig überzogen?
Kommt drauf an, was du ausgegeben haben willst bzw. was du anschliessend machen willst. Wenn du z.B. nur die PIDs der Prozesse willst, kannst du das mit awk direkt einbauen (einfach 'print $2;' statt 'print;'), mit dem grep musst du cat verwenden oder das grep durch sed ersetzen und dann mit sed die PID raussuchen... Fuer den einfachen Test (der aber oben fehlt), ob noch cronjobs laufen reicht aber das grep, deswegen steht das auch nicht auskommentiert da ;) z.B. folgendes: while ps -A j | grep -e "^ *$CRONPID " do sleep 60; done -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Am Freitag, 2. April 2004 00:20 schrieb David Haller:
Hallo,
Am Thu, 01 Apr 2004, Al Bogner schrieb:
ps -A j | grep -e ^$CRONPID
Hm. Bei mir wird die Spalte PPID rechtsbuendig ausgegeben, da klappt das nicht mit dem grep...
auszuwerten, ob da Zeilen zurückgegeben werden. Die PID von cron kannst du einfach aus /var/run/crond.pid auslesen.
Danke.
Denk dran: erst PID auslesen, dann crond beenden! Sonst gibt's nen
/var/run/cron.pid: No such file or directory
Hallo David, danke für deinen Hinweis. Ich hatte noch keine Zeit mich damit näher zu beschäftigen. Das Delay bei den Scripts, die per cronjob ins Internet gehen, dürfte in der Regel reichen, dass der Rechner heruntergefahren ist, bis das Script mit dem wesentlichen Teil beginnt. Al
participants (6)
-
Al Bogner -
Bernd Laengerich -
David Haller -
Martin Schmitz -
Matthias Houdek -
Peter Wiersig