Der Server hat 24 sichtbare Kerne und ich wahr sehr gespannt auf die Ausgabe der 24 Parallelen Aufrufe.

Leider brach der Test nach der Singlecore Überprüfung ab:

[root]# ./Run -c 24
...
Benchmark Run: Di Mai 08 2012 12:47:04 - 12:47:04
24 CPUs in system; running 24 parallel copies of tests

[root]#

Da ich aber auf einem anderen System mit 16 Cores schon gesehen habe, dass der Test auch generell mit mehr als 1 Core läuft war dies Merkwürdig. Der Fehler war hier in der Run selbst begraben. Dort ist folgendes definiter:

# Configure the categories to which tests can belong.
my $testCats = {
    'system'    => { 'name' => "System Benchmarks", 'maxCopies' => 16 },
    '2d'        => { 'name' => "2D Graphics Benchmarks", 'maxCopies' => 1 },
    '3d'        => { 'name' => "3D Graphics Benchmarks", 'maxCopies' => 1 },
    'misc'      => { 'name' => "Non-Index Benchmarks", 'maxCopies' => 16 },
};

Kein Wunder also, dass der 16 Core Server die Ausgabe ausgeführt hat und der 24 Core Server nicht.

Nach einer kurzen Änderung der “maxCopies” Variable auf 24 lief der Test auch sauber auf den 24 Cores durch.

Als erstes die suphp Konfiguration überprüft:

;PATH environment variable
env_path=/bin:/usr/bin

Dies sieht soweit korrekt aus, jedoch gab phpinfo() aus dass nur /bin im PATH registriert ist.

Nach einiger Recherche kam heraus, dass die debian default suphp.conf hier einen Fehler hat.

Damit beide Angaben genommen werden muss env_path über folgende Möglichkeiten gesetzt werden:

Variante 1:

env_path=/bin\:/usr/bin

Variante 2:

env_path="/bin:/usr/bin"

Für welche Variante man sich hier entscheidet ist egal, funktionieren tun beide.

Interessanter Weise gibt es auch einen Debian Bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647604

Soeben in einer Log gefunden:

postfix/smtpd warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer

Ich wusste schon immer, dass der Einsatz von Linux biologisch wertvoll ist :)

date -d @timetsamp

Also beispielsweise:

~$ date -d @1320057181
Mo 31. Okt 11:33:01 CET 2011

Ein Test mittels “quotaoff /” und “quotaon /” sagten, dass alles in Ordnung sei. Der Test mittels “quotaon -p -u /” lieferte das gewünschte Ergebnis:

user-Quota auf / (/dev/###) ist an

Selbst manuelles setzen der quotas führte zum Erfolg und das quota war aktiv.

Nun was war das Problem mit Confixx?

Letztendlich kamen wir auf die Lösung: Confixx prüft nicht etwa den Rückgabewert von quotaon -p -u / sondern erwartet den String “on”, sprich die englische Variante.

ein “unset LANG” und ein erneutes “quotaon -p -u /” brachten nun das on zu Tage:

user quota on / (/dev/###) is on

Ruft man nun die admin.pl mit nicht gesetzter locale auf kann quota auch direkt aktiviert werden.

Ist es nicht schön wenn Software plötzlich neue Dinge kann?

Ein Aufruf über telnet der entsprechenden Website lieferte mir immer das richtige Ergebnis, aber weder ein Firefox noch ein IE oder Opera konnten mir die Website anzeigen.

Verschiedene Einstellungen zur Contentauslieferung brachten leider keine Hilfe.

Ein Workaround ist nun, einfach alle Files durch den PHP Prozessor laufen zu lassen:

AddType application/x-httpd-php .php .phtml .php3 .html .htm

Dies ist zwar nicht unbedingt die Ressourcen schonend, allerdings funktioniert Mod Layout anschließend.

Die Logfiles die pipelog.pl anspricht werden aber leider auch nicht vom updateskript nachträglich generiert, also musste Hand angelegt werden:

for i in `ls /etc/apache2/confixx_vhosts`
do
  domains=`grep ServerName /etc/apache2/confixx_vhosts/$i | awk '{print $2}'`
  for j in $domains
  do
    ln -s /var/www/`basename $i .conf`/log/access_log /var/log/apache2/confixx/domains/access/$
  done
done

Ist es nicht schön eine bash zu haben? Nach der Generierung der Links liefen auch die awstats Updates wieder:

for i in `ls /var/www/`
do
  /usr/lib/cgi-bin/awstats.pl -config=$i -update
done

Das Bild im VServer

       ?  ? ?---------  ? ?        ?        ?            ? /var/mail/root

Das Bild außerhalb des VServers:

83363649 437981200 ?r-s--S-wt 8224 7217184 6627360 538976288 Jan 30  1987 root

Das ganze klingt ja schon spannend, allerdings lassen sich diese Dateien anschließend auch nicht mehr löschen, geschweige denn lesen:

~# chmod 600 /var/mail/root
chmod: changing permissions of `/var/mail/root': Operation not permitted
~# rm /var/mail/root
rm: remove write-protected weird file `/var/mail/root'? y
rm: cannot remove `/var/mail/root': Operation not permitted

Da allerdings über dmesg keinerlei Einträge auf einen Fehler im Dateisystem hingedeutet haben, war der einzigste Weg die Dateien zu löschen debugfs zu verwenden:

~# debufs
debugfs:  open -w /dev/sda3
debugfs:  cd /var/mail
debugfs:  rm root
debugfs:  close

Wichtig dabei ist das abschließende close, da ansonsten die Änderungen nicht auf das Dateisystem geschrieben werden.

Nun habe ich dank Matty (http://prefetch.net/blog/) einen entscheidenden Tipp bekommen: http://prefetch.net/blog/index.php/2008/07/09/bashs-built-in-commands/

Ich bin davor noch nicht auf die Idee gekommen mit den Keybindings direkt in der Bash herumzuspielen. Dank ihm konnte ich nun so endlich die “entf” Taste in Solaris verwenden:

bind '"\e[3~"':delete-char

Ab in die .bashrc :)

Vielen Dank matty! Du hast mir das Leben erleichtert.