The daemontools softwaresuite are widely used for supervising processes. Unlike the common way of launching daemons or other processes in background, writing their PID to a file and watch for a process (actually anyprocess) with this PID by crappy tools like monit the daemontools offer a direct supervision of processes with an immediate restart on a crash.

Using the traditional SysV-initit is most easy to launch the daemontools processes:

$ grep -B1 SV /etc/inittab
si::sysinit:/etc/rc.d/rc.sysinit
SV:12345:respawn:/command/svscanboot3

Note: svscanboot3 is a binary replacement of svscanboot. It is part of ngtx.

SysV-init process ID 1 is very small, approx. 700 KB RSS. With many manual optimizations it is possible to start a system / server as fast as with upstart or systemd.

Upstartoffers event-based booting. A time ago it was dealed as a successor to SysV-init. To start daemontools as a upstart-service you must create a config file:

$ cat /etc/init/daemontools.conf 
description     "DJB daemontools"
start on filesystem
stop on runlevel [06]
respawn
exec /command/svscanboot3

Some latest Linux (actual "linux-only") distros switch to systemd. Systemd also offers event-based and parallel booting with linux-only features like cgroups or fanotify. Its features are very nice but its PID 1 RSS is 13 MB which is very big compared to SysV-init. For systemd you must also create a config file (and a symlink):

$ ls -l /etc/systemd/system/multi-user.target.wants/ \
  daemontools.service
lrwxrwxrwx. 1 root root 39 21. Dez 08:34
  /etc/systemd/system/multi-user.target.wants/ \
  daemontools.service -> /lib/systemd/system/ \
  daemontools.service

$ ls -l /lib/systemd/system/daemontools.service
-rw-r--r--. 1 root root 151 21. Dez 08:33
  /lib/systemd/system/daemontools.service

$ cat /lib/systemd/system/daemontools.service
[Unit]
Description=DJB daemontools
After=sysinit.target

[Service]
ExecStart=/command/svscanboot3
Restart=always

[Install]
WantedBy=multi-user.target

Das Shell-Builtin "eval" bewertet Ausdrücke bzw. führt Befehle aus. Einfaches Beispiel:

$ unset A
$ echo $A

$ eval A=1
$ echo $A
1

Da die Shell vor Ausführen von eval wie auch bei jeder anderen Kommandozeile erst die üblichen Ersetzungen (Variablen, Commands etc.) macht, kann man auch folgendes machen:

$ B=A
$ eval $B=2
$ echo $A
2

Und wenn man ganz verrückte Sachen machen will, wie beispielsweise in einem Script mehrere Variablen in einer Schleife auf die gleiche Weise zu verändern, dann sieht das so aus:

$ U=a
$ for i in U;do eval $i=\"\$$i X\";done;echo $U
a X
$ for i in U;do eval $i=\"\$$i X\";done;echo $U
a X X
$ for i in U;do eval $i=\"\$$i X\";done;echo $U
a X X X

Wie erkennt man auf einem System, wie viele Prozessoren und Cores man hat, und ob Hyperthreading zur Verfügung steht? Fangen wir direkt mit einem Beispiel an:

s1# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @
1.60GHz
stepping        : 6
cpu MHz         : 1595.984
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts
pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr dca lahf_lm
bogomips        : 3194.84
clflush size    : 64
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @
1.60GHz
stepping        : 6
cpu MHz         : 1595.984
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts
pni monitor ds_cpl vmx tm2 ssse3 cx16 xtpr dca lahf_lm
bogomips        : 3192.06
clflush size    : 64
power management:

Hier sieht man das "ht"-Flag, aber der Xeon 5110 hat keinHyperthreading. Zum Vergleich mal ein anderes System:

s2# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping        : 1
cpu MHz         : 2995.049
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe constant_tsc pebs bts sync_rdtsc pni
monitor ds_cpl cid xtpr
bogomips        : 5994.31
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping        : 1
cpu MHz         : 2995.049
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe constant_tsc pebs bts sync_rdtsc pni
monitor ds_cpl cid xtpr
bogomips        : 5990.26
clflush size    : 64

Hier steht auch "ht", diesmal hat die CPU aber Hyperthreading. Das Flag wurde wegen einer gewissen Abwärtskompatibilität gesetzt. Grund waren unter anderem Betriebssysteme, die pro Sockel lizenziert wurden. Hätte man das mit dem Pentium4 eingeführte ht-Flag weggelassen, hätten diese "OS" den virtuellen zweiten Kern nicht genutzt / nutzen können.

Wichtig sind hierbei die Angaben zu den Siblings (so etwas wie gleichartige Kinder einer "Vater-CPU"), der Physical ID, der Anzahl der Cores und die Nummerierung der Core IDs. Mit grep wird das dann deutlicher:

s1# egrep \
'processor|physical id|siblings|core id|cpu cores|^$' \
/proc/cpuinfo
processor       : 0
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2

processor       : 1
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2

Wir haben 2 CPU cores mit ID 0 und 1 auf 1 physischen Prozessor bei 2 Siblings. die 2 Siblings beziehen sich hier auf die 2 Cores pro physischer CPU.

s2# egrep \
'processor|physical id|siblings|core id|cpu cores|^$' \
/proc/cpuinfo
processor       : 0
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1

processor       : 1
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1

Hier haben wir 2 (virtuelle) Prozessoren mit 1 physical ID, 1 Core ID und 1 CPU core, aber mit 2 Siblings. Es handelt sich somit um eine einzelne Singlecore-CPU. Die zwei virtuellen Prozessoren kommen durch die 2 Siblings zustande: Diese CPU hat also Hyperthreading. Pro Core hat man hier also "cpu cores" geteilt durch "siblings" = 2 / 1 = 2 virtuelle HT-Prozessoren.

Schauen wir uns einen dritten Server an:

s3# egrep processor /proc/cpuinfo
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15
root@coabmaster:~ > egrep 'core id' /proc/cpuinfo|sort -u
core id         : 0
core id         : 1
core id         : 2
core id         : 3

Wir haben 16 virtuelle/nicht-virtuelle Prozessoren und 4 Kerne pro physischem Prozessor.

s3# egrep \
'siblings|cpu cores|physical id' /proc/cpuinfo \
|sort -u
cpu cores       : 4
physical id     : 0
physical id     : 1
siblings        : 8

Hier sieht man noch mal die Anzahl der Kerne, die IDs der physischen Prozessoren und 8 Siblings (8 Siblings durch 4 Cores = 2 virtuelle HTT-CPUs). Das macht also 2 Quadcore-CPUs mit Hyperthreading = 16 virtuelle Prozessoren.

Mit einem kleinen Script lässt sich das bequem auswerten:

s4# cat cpucores.sh 
#!/bin/bash

for f in \
  'model name' processor 'physical id' 'cpu cores' siblings
do
  grep "$f" /proc/cpuinfo|tail -n 1
done \
|sed 's,.*: ,,' \
|{
  read M
  read P;let P=P+1
  read I;[ -z "$I" ] && I=0;let I=I+1
  read C;[ -z "$C" ] && C=1
  read S;[ -z "$S" ] && S=1
  echo $M: $I CPUs with $C cores and $S siblings\
    $([ $S -gt $C ] && echo " (hyperthreading)") \
    '("'$P virtual processors'")'
}
s4# ./cpucores.sh 
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz: 2 CPUs with 4 cores and
8 siblings (hyperthreading) ("16 virtual processors")

Da das Script so kurz ist, kann man es auch als Einzeilerverwenden. Zum Schluss noch ein paar Beispielausgaben des Scripts:

Intel(R) Xeon(R) CPU E5520 @ 2.27GHz: 2 CPUs with 4 cores and
8 siblings (hyperthreading) ("16 virtual processors")
Intel(R) Xeon(R) CPU X5650 @ 2.67GHz: 2 CPUs with 6 cores and
12 siblings (hyperthreading) ("24 virtual processors")
Intel(R) Pentium(R) 4 CPU 3.00GHz: 1 CPUs with 1 cores and 2
siblings (hyperthreading) ("2 virtual processors")
Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz: 1 CPUs with 2 cores
and 2 siblings ("2 virtual processors")
Intel(R) Xeon(R) CPU 3060 @ 2.40GHz: 1 CPUs with 2 cores and
2 siblings ("2 virtual processors")
Intel(R) Xeon(R) CPU 5110 @ 1.60GHz: 4 CPUs with 2 cores and
2 siblings ("4 virtual processors")
Intel(R) Xeon(R) CPU E5310 @ 1.60GHz: 1 CPUs with 4 cores and
4 siblings ("4 virtual processors")
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz: 2 CPUs with 4 cores and
8 siblings (hyperthreading) ("8 virtual processors")
Intel(R) Xeon(R) CPU E5620 @ 2.40GHz: 2 CPUs with 4 cores and
8 siblings (hyperthreading) ("8 virtual processors")

Das ist auch ein kleiner Klassiker, darum sollen dieses Problem und seine Lösung auch nicht unerwähnt bleiben. Es kann vorkommen, dass in einem Apache Error-Log die folgende Zeile auftaucht:

No space left on device (errno: 28)

Eine Prüfung ergibt dann oft, dass auf den (HD-) Devices sehr wohl noch "Space" vorhanden ist. In den Logzeilen findet sich dann auch ein Eintrag wie:

could not create private SSLMutex semaphore

Das liefert dann auch den entscheidenden Hinweis darauf, dass Apache keinen neuen Semaphor (ein klassisches Werkzeug für IPC) erzeugen kann. Die man-page zu semget() führt auch diese Fehlermöglichkeit auf:

# man semget|grep -A4 ENOSPC
   ENOSPC A semaphore set has to be  created  but  the
          system limit for the maximum number of sema-
          phore sets (SEMMNI), or the system wide max-
          imum number of semaphores (SEMMNS), would be
          exceeded.

Das sind bei vielen Hosts oft noch die zu niedrigen Standardwerte:

# cat /proc/sys/kernel/sem 
250     32000   32      128

Die man-page proc(5) liefert uns folgende Infos dazu:

   /proc/sys/kernel/sem (since Linux 2.4)
          This file contains 4 numbers defining limits for
          System  V  IPC semaphores.  These fields are, in
          order:

          SEMMSL  The  maximum  semaphores  per semaphore
                  set.

          SEMMNS  A  system-wide  limit  on  the number of
                  semaphores in all semaphore sets.

          SEMOPM  The maximum number  of  operations that
                  may be specified in a semop(2) call.

          SEMMNI  A  system-wide limit on the maximum num-
                  ber of semaphore identifiers.

Eine Zählung der Semaphore des Users "www" liefert das:

# ipcs -s|grep -c www
128

Jetzt stoppen wir Apache, löschen alle "vergessenen" Semaphore, setzen die Werte höher und starten Apache wieder:

# ipcs -s|grep www|cut -d\  -f2|xargs -r -n 1 ipcrm -s
# echo '500 64000 32 1024' >/proc/sys/kernel/sem 

Dieser Post zeigt ein paar Möglichkeiten, wie man Befehle oder Ausgaben in einer Shell-Session mitschneiden kann.

Der Befehl script erzeugt eine neue Shell, bei der alle Ein- und Ausgaben in eine Datei typescript geschrieben werden. Nach Verlassen der durch script gestarteten Shell kann man sich dieses Logfile anschauen. Allerdings ist dort jedes einzelne Zeichen aufgezeichnet, einschliesslich aller Steuerzeichen für Farben, für Zeilen Editierung (Backspace, Tab, Return etc). Wie man mittels vi dieses Log von Steuerzeichen befreit, würde diesen Beitrag sprengen.

Als Alternative kann man sich auch nur die Textausgabe von Programmen in ein Logfile packen. Hier ein Beispiel:

$ avscan -a . 2>&1 |tee -a log.avscan

Wenn man ein Logging mit Timestamp der einzelnen Zeilen braucht, kann man so etwas machen:

$ /opt/drweb/drweb -al . 2>&1 |tai64n |tee -a log.drweb
@400000004c5bbe8b1d775b9c Dr.Web (R) Scanner for Linux
@400000004c5bbe8b1e3010c4 Copyright (c) Igor Daniloff,

Das Tool tai64n gehört zu der Softwaresuite daemontools von Dan Bernstein. Hier fügt tai64n am Beginn jeder Zeile einen Timestamp @40000... ein. Lesen/konvertieren kann man das mit tai64nlocal, was den tai64n-Timestamp in lokale und human readable Zeit konvertiert:

$ tai64nlocal <log.drweb |tail -1
2010-08-06 09:43:03.225062500 2009_02_12-ftp.log.gz - Ok
$ 

Man kann sich den "Live-Stream" auch direkt bei der Ausgabe wieder konvertiert anzeigen lassen:

$ /opt/drweb/drweb -al . 2>&1 |tai64n \
  |tee -a log.drweb |tai64nlocal
2010-08-06 09:47:52.433362500 Dr.Web (R) Scanner for Linux
2010-08-06 09:47:52.433364500 Copyright (c) Igor Daniloff,

Wenn man mit sehr viel Daten bei der Ausgabe rechnet und vielleicht nur den letzten Teil haben möchte, dann kann man so eine Zeile nutzen:

$ /opt/drweb/drweb -al . 2>&1 |tee /dev/stderr \
  |multilog t s10000 n20 ./logdir

Diese Zeile zeigt die Programmausgabe kontinuierlich an und schreibt bis 20 maximal 10 KB große Logdateien in das Verzeichnis logdir. Das Tool multilog aus den daemontools hat ein eingebautes "logrotate". Auf diese Weise kann man die Menge der Logdaten begrenzen.

Auch wenn die "großen" Zeiten von Tcl/Tk ("Tickel-Tikay") vorbei sind, es gibt immer noch einige Leute, die die Scriptscprache und das Toolkit nutzen. Es ist stabil und gut dokumentiert. Ein aus dem Tcl-Umfeld entstandenes Programm ist expect, mit dem man Interaktionen bzw. Dialoge mit anderen Programmen oder auch Serverdiensten realisieren kann.

Die man-page zu expect erklärt die Grundlagen. Hier ist ein Beispiel für die Verwendung von expect aus einem bash-Script heraus:

> cat check_easyraid.sh 
#!/bin/bash

CMD=$1
[ "$CMD" ] || {
  echo "usage: echo PASSWD | $0 easyraidcommand ip-address"
  exit 1
}
IP=$2
[ "$IP" ] || exit 2
ulimit -t 4
read -t 1 PASS

cat <<EOF |expect -|egrep 'Disk State:|State :|s status is'
match_max 65536
spawn telnet $IP
expect "name:"
send "admin\n"
expect "passwd:"
send "$PASS\n"
expect "ACSCLI"
send "$CMD\n"
#interact -nobuffer -re "Disk State:"
expect "ACSCLI"
#send_user "output: $expect_out(buffer)"
send "quit\n"
close
EOF

Das Script baut eine telnet-Session zu einem easyRAID-SAN auf und schickt Befehle zum Testen ab. Man kann mit expect auch ftp-Sessions oder andere Interaktionen aus Scripts heraus einfach handhaben. Das Beispiel ist ein Mix aus bash und expect, aber man kann mit dem passenden Shebang natürlich auch "reine" expect-Scripts schreiben.