Ein cooler Tipp von Christian:

Wer regelmäßig auf mehreren Konsolen gleichzeitig per ssh arbeitet, der hat mit Sicherheit schon einmal versehentlich im falschen Fenster einen System-Shutdown ausgelöst. Und schwupps ist der falsche Server heruntergefahren.

Hier helfen die Scripts aus dem Debian-Paket “molly-guard” weiter. Diese installieren in /usr/sbin/ Links mit dem Namen der eigentlichen Shutdown-Befehle (halt, poweroff, shutdown und reboot) auf /usr/share/molly-guard/shutdown. Löst man nun eines dieser Scripte aus, verlangt molly erst nach der Eingabe des herunterzufahrenden Servernamens.

Spätestens hier kann man einen fast begangenen Fehler noch verhindern.

Blöd ist nur, dass ich meist “init” benutze, um meine Systeme herunterzufahren oder neu zu starten, und das wird von molly-guard nicht berücksichtigt… ich werde das Script auf jeden Fall einmal entsprechend anpassen und testen, ob es irgendwo zu Wechselwirkungen kommen kann.

Das Testergebnis gibt’s dann hier.

Links:
blog.256bit.org

Edit
Ein paar kleine Tests haben - auch mit verlinktem “init” und angepasstem Script bisher funktioniert. Wer’s ausprobieren möchte:
# ln -s /usr/share/molly-guard/shutdown /usr/sbin/init
und im Shutdown-Script die Zeilen

case “$CMD” in
halt|reboot|shutdown|poweroff)
if [ ! -f $EXEC ]; then

ändern zu:

case “$CMD” in
init|halt|reboot|shutdown|poweroff)
if [ ! -f $EXEC ]; then

.

Das Ganze ist allerdings ohne Gewähr.

Dass Citrix mit Druckern schon von jeher seine Schwierigkeiten hat, war mir ja bekannt. Aber als wir jetzt auf unserem Printserver die Treiber für die vorhandenen Laserdrucker aktualisiert und die Treiberversionen auch auf den Citrix-Servern entsprechend angepasst hatten, wurde es heftig.

Sobald jemand aus einer Citrix-Anwendung (Citrix Metaframe 3.0 auf Windows Server 2003) einen Ausdruck anforderte oder eine Anwendung beenden wollte, stürzte der Server, über den die Anwendung freigegeben war ab und startete neu.

Der einzige Kommentar nach dem Hochfahren der Server: “Systemabbruchfehler: 0×000000ab”.

Lustig, wenn dann mehrere hundert Leute gleichzeitig bei einem anrufen. Da bekam gleich die Telefonanlage noch einen Belastungstest.

Der glücklicherweise schnell gefundene Microsoft-Knowledgebase-Artikel 946068 lieferte eine schlüssige Erklärung:

Dieses Problems wird dadurch verursacht, dass einige Objekte, die der Treiber Win32k.sys aus dem Sitzungspool zuordnet, vor den Sitzungsenden nicht freigegeben werden. Defekte Druckertreiber verursachen möglicherweise diese Bedingung zu Speicherverlusten. Um das System von dem Fortsetzen des Systems in einem instabilen Zustand zu verhindern, gibt der Speichermanager in Fall einen Abbruchfehler aus.

Also schnell beim Redmonder Softwareriesen angerufen und das im KB-Artikel angesprochene Hotfix angefordert.

Zwei Minuten später hatte ich tatsächlich eine E-Mail mit einem Downloadlink im Postfach.

Und siehe da: Nach der Installation des Hotfixes (und des bei Microsoftprodukten obligatorischen Neustarts des Systems) gab es keine Systemabstürze mehr.

Aber auch keine Ausdrucke. Je nach Anwendung gab es einfach keine Reaktion auf eine Druckanforderung oder einen Anwendungsabsturz.

Erst eine Neuzuweisung der Druckertreiber zu jedem betroffenen Drucker brachte hier die Lösung. Macht Spaß, wenn man das ca. 100 Mal machen muss. *grmpf*