Schon seit vielen Jahren baue ich nur noch Linux-Kernels selber, wenn es wegen Treibern o.ä. gar nicht anders geht. Ansonsten bleibt immer der Kernel aus der Distribution drauf. Das sichert auch ein anständiges Update mit dem Packetmanager des Systems.
Wie immer werfe ich mein Update also mit
aptitude safe-upgrade an und lasse den Kernel mit updaten. Geht immer Problemfrei. Aber heute hatte ich mal wieder so einen Mist-die-Installation-ist-schon-älter-Effekt. Das ist beim Debian absolut nichts schlimmes. Aber zu erkennen ist es daran, dass ich der /boot-Partiton nur 100MB gegönnt habe. Das hat früher immer ausgereicht. Aber neue Kernels werden auch immer größer. Und so kam es, dass beim Update die Initramdisk für den 3.2er Kernel keinen Platz mehr fang.
update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae
gzip: stdout: No space left on device
cpio: Fehler beim Schreiben: Datenübergabe unterbrochen (broken pipe)
E: mkinitramfs failure cpio 1 gzip 1
update-initramfs: failed for /boot/initrd.img-3.2.0-4-686-pae with 1.
dpkg: Fehler beim Bearbeiten von initramfs-tools (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
initramfs-tools
Ein
df -h zeigte auch gleich an, dass die Partition voll ist. Hätte ich so rebootet wäre das System nicht mehr hochgekommen. Was bei einem Webserver ohne Zugriff auf eine lokale Konsole fatal ist.
Gelöst bekommt man das Problem ganz einfach. Einmal ein
dpkg -l linux-image-* abschicken und ich kann sehen, welche Kernels noch alle Installiert sind. Mit der Ausgabe rollt man das Problem jetzt von hinten auf und deinstalliert die alten Kernels einfach in aufsteigender Versionsnummer bis nur noch die notwendigen Kernels vorhanden sind. Das sieht dann so aus:
aptitude remove linux-image-2.6-686 linux-image-2.6.32-5-686 linux-image-3.0.0-1-686-pae linux-image-3.1.0-1-686-pae.
Beim Deinstallieren des Kernels werden auch die Init-Ramdisks, die beim installieren eines Kernels erstellt werden, wieder mit entfernt. Ich hab also danach wieder genug Platz frei.
Das schöne daran ist, dass der Debian-Packetmanager auch gleich mitbekommt, dass der aktuelle Kernel nicht vollständig installiert ist. Nachdem die alten Kernels deinstalliert sind, baut der also automatisch die fehlende Initramdisk nach und das System ist wieder bootfähig.
Der Ablauf ist absolut nichts schwieriges. Aber er taucht bei mir so selten auf, dass ich nicht vor einem Update auf die Größe der /boot Partition schaue. Also dachte ich mir, ich präg mir das jetzt mal durch Bloggen ein...
Es gibt so Tage, an denen will man direkt nach dem ersten Kontakt mit Windows gleich wieder Feierabend machen. Ich hab mich ja bereits an vieles Gewöhnt, seit dem ich wieder so viel Fenstern muss, aber die Implementierung, die mir eben unter gekommen ist, verlangt nach einem lauten Aufschrei.
Linux-Admins wird es bekannt vorkommen. Auch unter Windows gibt es den Befehl
at zum einrichten von Tasks. Im Gegensatz zur Linux Version kann man dort aber auch mit dem Parameter
/EVERY wiederkehrende Tasks mit anlegen. Als Werte können dann entweder die Tage im Monat als Zahl angegeben werden oder die Wochentage mit einem Kürzel. Also z.B. "m" für Monday. Aufpassen muss man nur beim Thursday. Denn der Beginnt mit dem selben Buchstaben wie der Tuesday. Also verwendet man für den Thursday halt th. Alles logisch. Vor allem, wenn man sich die Hilfe anschaut.
Auf meinem Testsystem führt also folgender Aufruf zum gewünschten Ergebnis und führt jeden Montag (m=monday) einen Reboot aus...
at localhost 08:00 /EVERY:m "c:Scriptssystem_reboot.cmd"
Also alles Verifiziert. Reboot klappt. Ab damit auf meine Produktionskiste. Pustekuchen. Nichts geht. Befehl wird abgelehnt. Nochmal nachschauen. Vertippt? Nein. Moment. Produktionskiste hat jemand in Deutsch installiert. Mir schwant böses. Bei meiner Vermutung fange ich schonmal mit einem leichten Kopfschüttelt an. Das kann doch nicht wirklich stimmen. Oder?
Also kurz die Hilfe über "Hilfe und Support" im Startmenü aufgerufen und Peng:
Wie bitte? Willste mir vera...? Ja. Will er.
Aber was soll's. Also Reverse Engeneering. Befehl kurz abgewandelt und ein "/EVERY:mo" draus gemacht und zack. Funktioniert.
Die Knalltüten haben allen ernstes die Aufrufparameter Sprachabhängig gemacht. Ich kann wohl froh sein, dass der Parameter noch EVERY und nicht WIEDERHOLUNG heisst. Liebe Leuts in Redmond. Wie soll sowas denn in gemischten Umgebungen zum Scripten taugen???
Nach so einem kompetenten Hilfefenster und dem hochgradig durchdachten Befehlsaufruf so direkt aufeinander brauch ich jetzt erstmal ein Käffchen...
Die letzten Tage waren die Newsticker voll von einer Schlagzeile: Die Schaltsekunde!
In der Nacht zum 01.07. ist mal wieder eine Schaltsekunde eingefügt worden, um die Verluste auszugleichen. Der Linux-Kernel stolpert dabei leider in einigen Versionen und erzeugt eine Endlosschleife, die die CPU mal kurz auf 100% laufen lässt. Die Mail von Hetzner in meinem Postfach hat dabei den ersten Platz gewonnen. Die haben in den Statistiken einen schönen Stromanstieg im 1 Megawatt zum Zeitpunkt der Einführung der Schaltsekunde gemessen. und da dieser "Peak" auch Tage später noch anhält, wurden alle Kunden aufgefordert ihren Server zu checken und ggf. zu rebooten.
Beim Check haben sich auch gleich ein paar Sachen ergeben, die ich im Themenkreis "Stromsparen" gleich mit gecheckt habe.
Neue CPUs können die Taktfrequenz reduzieren, um Strom zu sparen. Unter Linux kann dieses Verhalten mit der Software "cpufrequtils" erledigt werden. Mit dem gleichnamigen Debian-Packet installiert sich die Konfig-Dateiei /etc/default/cpufrequtils. Der GOVERNOR stellt dabei ein, wie sich die CPU verhalten soll. Bei mir war das per Default "performance", was so viel wie "immer auf max speed" bedeutet. Ein Einfaches Umstellen auf ondemand sorgt dafür, dass die CPU sich in ruhigen Zeiten runtertaktet. Kontrollieren lässt sich das mit dem Befehl cpufreq-info:
# cpufreq-info
cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@lists.linux.org.uk, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0 1
hardware limits: 1000 MHz - 2.80 GHz
available frequency steps: 2.80 GHz, 2.60 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: conservative, powersave, userspace, ondemand, performance
current policy: frequency should be within 1000 MHz and 2.80 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
cpufreq stats: 2.80 GHz:99.35%, 2.60 GHz:0.00%, 2.40 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.80 GHz:0.02%, 1000 MHz:0.63% (10253)
analyzing CPU 1:
driver: powernow-k8
CPUs which need to switch frequency at the same time: 0 1
hardware limits: 1000 MHz - 2.80 GHz
available frequency steps: 2.80 GHz, 2.60 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz
available cpufreq governors: conservative, powersave, userspace, ondemand, performance
current policy: frequency should be within 1000 MHz and 2.80 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1000 MHz (asserted by call to hardware).
cpufreq stats: 2.80 GHz:99.35%, 2.60 GHz:0.00%, 2.40 GHz:0.00%, 2.20 GHz:0.00%, 2.00 GHz:0.00%, 1.80 GHz:0.02%, 1000 MHz:0.63% (10253)
Wichtig sind dabei die Zeilen "current policy" und "current CPU frequency". Dort ist zu sehen, dass meine CPU aktuell auf 1GHz gelaufen ist. Der Rest verrät mir dann auch gleich noch ein bischen über die Fähigkeiten der CPU.
Eine weitere kleine Vorkehrung, die ich inzwischen immer aktiviere, ist der Parameter "noatime" beim mounten von Dateisystemen. Einmal die /etc/fstab gecheckt und schon war zu sehen, dass dies auf dem Server noch nicht aktiv ist. noatime verhindert, dass die Access-Time einer Datei, also der letzte Zugriff auf diese Datei, in der Inode gespeichert wird. Dieser unscheinbare kleine Schalter macht also aus jeder Lese-Operation auch gleich ein Schreibzugriff auf das rotierende Rost. Das kostet Zeit, drückt auf die Geschwindigkeit und verbraucht (wenn auch nur in geringen Mengen) mehr Strom. Also abschalten...
In der fstab wird dazu die Spalte der Mountoptionen angepasst.
/dev/md2 / ext3 defaults,noatime 0 0
Da die fstab nur beim mounten eingelesen wird, müsste ich den Server rebooten. Will ich aber nicht. Also fix ein remount abgeschickt:
# mount -o remount /
Danach ist die noatime-Einstellung für die Platte gesetzt und ein Lesezugriff bleibt ein Lesezugriff. Checken kann man das ebenfalls mit mount:
# mount
/dev/md2 on / type ext3 (rw,noatime)
Es gibt bestimmt noch mehr kleine Tips zum Energiesparen oder Performance erhöhen. Wenn Ihr welche habt, hinterlasst sie einfach als Kommentar unter diesem Beitrag.
Normalerweise ist sowas ja nicht notwendig. Aber ab und an hängt sich doch mal eine GUI auf. Bei mir beliebt bei bestimmten Grafiktreibern, die nur Binär vorliegen und ohne die die Grafikkarten des nicht näher benannten Herstellers nur das Mindestmaß an Funktionalität zur Verfügung stellen.
Im Admin-Magazin ist ein kleiner Admin-Tip veröffentlicht worden, wie man in solchen Fällen den Totalreset evtl. vermeiden kann...
Admin-Tip: Notausgang
Ist es mir doch in letzter Zeit häufiger passiert, dass die Zeit des einen oder anderen Servers leicht abgedriftet ist. Besonders ärgerlich ist dass, wenn der Server die Angewohnheit hat zu hetzen und schon ein paar Minuten weiter ist als alle anderen...
Unter Linux verwende ich dafür für die erste Korrektur immer ntpdate. Einfach per
ntpdate <zeitserver> den Abgleich anwerfen und es wird die synchronisierte Zeit und der ausgeglichene Offset angezeigt. Hat man allerdings Dienste wie z.B. den IMAP-Server Dovecot laufen, finden die das z.T. garnicht witzig, wenn die eine Zeitepoche auf einmal noch ein weiteres mal durchleben sollen. Dovecot quittiert dies z.B. mit einer Arbeitsverweigerung bis der wiederholte Zeitabschnitt verstrichen ist.
Prinzipiell gibt es dafür jetzt zwei Lösungsmöglichkeiten. Die eine davon ist das Packet
ntp nachzuinstallieren. Darin enthalten ist der Zeitserver
ntpd, den man mit der Anweisuung
server in der Datei
/etc/ntp.conf auf den gewünschten Zeitserver schickt und dann startet. Die Zeit wird vom ntpd dann im Hintergrund syncron gehalten. Empfehlenswert ist es trotzdem vorher einmal mit ntpdate manuell die Zeit zu synchronisieren, da ein zu großes Offset vom ntpd nicht ausgeglichen wird.
Die zweite Version ist etwas konsequeter, weil sie auch bei größeren Offsets arbeitet. Dafür wird das Packet
ntpdate installiert. Unter Debian wird danacj in der Datei
/etc/default/ntpdate die Einstellung
NTPDATE_USE_NTP_CONF auf
no gesetzt. Die Zeile mit
NTPSERVERS kann bei bedarf erweitert werden. Damit die Zeitsynchronisation regelmässig ausgeführt wird, wird noch ein passender Cronjob erstellt. Am besten ruft man dafür den Befehl
crontab -e
auf, um die Crontab mit dem Default-Editor zu bearbeiten.
# m h dom mon dow command
*/5 * * * * /usr/sbin/ntpdate-debian 2>&1 >/dev/null
Damit wird alle 5 Minuten einmal die Zeit abgeglichen. Je nachdem wie stark die Systemuhr abdriftet kann man hier auch größere Abstände konfigurieren. Das Zeilenände "2>&1 >/dev/null" leitet alles Ausgaben in die Mülltonne. Dies sollte man unbedingt mit angeben. Sonst produziert der Befehl alle 5 Minuten eine Mail, die an den Systemadministrator geht.
Alle hier beschriebenen Befehle müssen als root-User ausgeführt werden, da die Änderung der Systemzeit nur durch diesen User zu erledigen ist.
Unter Ubuntu sollte der Ablauf der gleiche sein. Hier muss lediglich vor jeden gezeigten Befehl ein
sudo vorgestellt werden, da Ubuntu per Default mit deaktiviertem Root-Account arbeitet.