Artikel mit ‘shell’ getagged

Die Annalen der Bash-Geschichte

Dienstag, 02. Oktober 2012

Heute mal wieder eine Episode aus den „adventures in modern computing“.

Wer die Bash (oder eine andere gängige Shell, hier geht es aber spezifisch um die Bash) kennt, wird höchstwahrscheinlich ihre äußerst nützliche History-Funktion kennen. Die Bash loggt die Befehle die man auf ihr eingibt und hält sie in einem Puffer bereit, auf den man verschiedentlich zugreifen kann um Befehle erneut auszuführen, anzupassen oder sich einfach ins Gedächtnis zu rufen. In erster Linie ist dies wohl als Arbeitserleichterung gedacht, es hat aber auch Anklänge eines regelrechten Logs, allerdings mit der Einschränkung, daß in der History normalerweise nur die 500 letzten Befehlszeilen vorgehalten werden (mit ein paar Tricks drumherum, z.B. kann man das mehrfache Speichern wiederholter Befehle ganz oder teilweise vermeiden). 500 wird heute vielen als ein vergleichsweise kleiner Wert erscheinen und das sehen offenbar die meisten Betriebssystem-Schmiede genauso und liefern ihre Software mit höheren Voreinstellungen aus (manchmal nur 1000 Zeilen, manchmal aber auch 10000 oder 40000 oder noch mehr). Speicher ist schließlich billig, oder?

Nun, wer eine SSD sein Eigen nennt sieht das vermutlich etwas anders, aber vor allem gibt es noch einen anderen Speicher der nicht sooo billig ist: RAM. Normalerweise liest die Bash nämlich den gesamten Inhalt ihrer History-Datei ein wenn sie startet. Das verlangsamt den Start der Bash und erhöht ihren RAM-Bedarf. Wer also die Bash History auch als Log nutzen möchte und daher die Variable $HISTSIZE auf einen sehr hohen Wert setzt, zahlt dafür mit verringerter Performance. Das fällt auf aktuellen Computern vermutlich gar nicht mal so sehr auf, zumindest bis die Datei so allmählich über ihre ersten Megabytes hinaus gewachsen ist. Auch für diesen Fall ist in der Bash bereits vorgesorgt: es gibt neben der Variablen $HISTSIZE noch die Variable $HISTFILESIZE, erstere definiert wie viele Zeilen der Datei beim Starten der Bash in den Puffer gelesen werden, letztere ist nützlich, um die tatsächliche Größe der Datei (in Zeilen, nicht in Byte) abweichend zu definieren. Eine Möglichkeit ist also, $HISTSIZE vergleichsweise klein zu wählen und $HISTFILESIZE extrem groß zu wählen. So spart man RAM und auch etwas Zeit beim Starten der Bash, kann aber sehr viele Befehle in der History halten. Die sind dann zwar nicht direkt über Funktionen der Bash zugänglich, aber es gibt ja noch die Möglichkeit die Datei zu durchsuchen, z.B. mit dem Programm grep.

Nun würde ich aber gerne ein ewiges Log haben. Auf Kundensystemen ist das zwar kein Ersatz für eine gute Dokumentation des Setups, aber es ist eine gute Ergänzung dazu. Auf meinen eigenen Computer will ich das sogar noch viel mehr, weil ich da auch häufiger mal Dinge ausprobiere, für die ich gar keinen alltäglichen Nutzen habe, an die ich mich aber gerne „erinnern“ können möchte, selbst wenn es nur Spielereien sind wie etwa „Twitter auf der Kommandozeile nutzen“ oder „Nachgucken was für ein Wochentag ein bekanntes historisches Datum hatte“ oder dergleichen. Hier habe ich dann unweigerlich das Problem, daß die History auf mehr Zeilen anwachsen könnte als ich in $HISTFILESIZE erlaubt habe. Zwar kann ich den Wert dort sehr hoch setzen, sogar lächerlich hoch, aber trotzdem ist es eine Grenze und es ist weiterhin nötig, daß die Bash sich anschaut wie groß die Datei überhaupt ist, was mir ja völlig egal wäre. Zumal ich stark annehme, daß ich niemals mehr Zeilen in der History-Datei erlauben könnte als die Bash als größte Zahl unterstützt. Die Bash selbst mag zwar nicht typisiert sein, aber trotzdem wird sie nicht unendlich lange Zahlen verarbeiten können.

Ich hab ein bißchen rumprobiert, konnte aber keine wirklich gute Lösung finden. Laut Dokumentation bewirkt eine $HISTFILESIZE von 0, daß gar keine History-Datei unterhalten wird. Ich würde da am liebsten „unendlich“ reinschreiben, aber das geht nunmal nicht. Die Dokumentation der Bash sagt aber noch, daß das Fehlen der Variable $HISTFILESIZE dazu führen würde, daß die Datei beliebig groß sein darf. Also änderte ich meine .bashrc:

export HISTSIZE=10000
#export HISTFILESIZE=1000000000000000000
unset HISTFILESIZE

Das hatte aber nicht den gewünschten Effekt. Die Bash setzte den Wert von $HISTFILESIZE beharrlich auf 10.000, also den gleichen Wert wie $HISTSIZE. Nur warum?

Ich überlegte bereits, mir eine Logrotate-Config für die History-Datei zu erstellen (das mache ich vielleicht trotzdem noch), aber es ließ mich nicht in Ruhe, daß das nicht mit „Bordmitteln“ der Bash funktionieren wollte, denn eigentlich sollte das was ich mir wünschte durchaus gehen. Nach längerem vergeblichen Suchen (ich kann gar nicht oft genug erwähnen, wie sehr ich Foren hasse), hab ich dann auf einer Mailingliste den entscheidenden Hinweis gefunden: Die Bash liest zuerst ihre Configs ein und dann die History-Datei und wenn zu diesem Zeitpunt die Variable $HISTFILESIZE nicht gesetzt ist, wird sie auf den gleichen Wert gesetzt wie $HISTSIZE. Das ist natürlich vollkommen bescheuert, denn dann kann ich ja de facto diese Variable nicht nicht setzen, jedenfalls nicht in einer Config der Bash. Ich müßte also nach jedem Start einer Bash manuell ein „unset HISTFILESIZE“ auslösen, damit meine History nicht auf 10.000 Zeilen zusammengekürzt wird. Unpraktisch.

Wie soll man also die $HISTFILESIZE nicht setzen können, wenn ihr Fehlen gleichzeitig dazu führt, daß sie automatisch gesetzt wird? Ich erinnerte mich düster, daß die Bash durchaus einen Unterschied macht zwischen gar nicht gesetzten Variablen und gesetzten Variablen denen kein Wert zugewiesen wurde, also „NIL“ sind, wie man so schön sagt. Vielleicht meinte die Dokumentation genau das?

Sie meinte es. Dieser Teil meiner .bashrc sorgt für eine History-Datei ohne Größenbegrenzung, von der dann die letzten 10.000 Zeilen in den History-Puffer geladen werden:

# read this number of lines into history buffer on startup
# carefull with this, it will increase bash memory footprint and load time
export HISTSIZE=10000
# HISTFILESIZE is set *after* bash reads the history file
# (which is done after reading any configs like .bashrc)
# if it is unset at this point it is set to the same value as HISTSIZE
# therefore we must set it to NIL, in which case it isn't "unset",
# but doesn't have a value either, go figure
#unset HISTFILESIZE
export HISTFILESIZE=""

Wie George Takei sagen würde: Oooh my!

Defekte Quota-Dateien in Ordnung bringen

Montag, 05. Oktober 2009

Dann und wann ist das Quota-System ein bisschen empfindlich. Spätestens wenn man in /var/log/messages sowas hier liest …

Oct  1 04:18:37 server4 kernel: VFS: find_free_dqentry(): Data block full but it shouldn't.
Oct  1 04:18:37 server4 kernel: VFS: Error -5 occured while creating quota.

… weiß man: Da ist mehr im Argen, als man mit einem einfachen quotacheck korrigieren kann. Nun lassen sich zwar mit quotacheck -c prima neue, frische Quota-Dateien anlegen, nur: Dann haben die User alle erstmal keine Quota mehr. Das ist natürlich schlecht.

Ich habe daher, da repquota noch brauchbare Ergebnisse lieferte, erstmal den Ist-Stand in einer Datei gesichert. Dann quotaoff, quotacheck, quotaon. Keine Fehler mehr, aber eben auch keine gesetzten Quotas mehr. Hier mein quick-and-dirty-Hack dafür, um aus der gesicherten repquota-Ausgabe noch Daten zu übernehmen (die fraglichen Usernamen begannen alle mit „web…“, jaja: Confixx natürlich, aber das Beispiel funktioniert natürlich auch woanders):

for LINE in `cat /root/repquota.2009-10-01 | grep ^web | sed 's/ \+/:/g;'` ; do
  setquota `echo $LINE | awk -F : '{ print $1,$4,$5,$7,$8 }'` / ;
done

Wieso ich hier die Leerräume durch Doppelpunkte ersetze? Ganz einfach: Die for-Schleife der Shell benutzt Leerräume als Trennzeichen, und die Leerräume zwischen den einzelnen Spalten würden genauso behandelt wie die Leerräume, die durch die Zeilenumbrüche entstehen. Die Schleife würde also nicht so oft laufen, wie Zeilen vorhanden sind, sondern so oft, wie Zeilen*Spalten vorhanden sind. Also: Doppelpunkte, weil die weder in den Usernamen noch in den Quota-Werten vorkommen. Und awk kann ganz hervorragend daran splitten.


Impressum