Version vom 15. Oktober 2020, 16:08 Uhr

Linux- Prozessverwaltung

Prozesse bilden das tragende Konzept eines jeden Betriebssystems. Prozesse werden gestartet, angehalten, reaktiviert, beendet, ihre Ausgaben unterbunden usw.

Alle Maßnahmen, die die Arbeit der Prozesse beeinflussen, fasst man daher unter dem Begriff der Prozesssteuerung zusammen.

Die Shells tragen der Bedeutung solcher Mechanismen Rechnung, indem sie unterschiedlichste Möglichkeiten bieten, Prozessen die Richtung zu weisen.

Wenn die Festplatte kreischt, oder der Bildschirm flimmert, wenn die Soundkarte tönt oder der Prozessor sich erhitzt,... - immer dann zeichnet ein Prozess dafür verantwortlich.

Programme sind die Ablaufpläne, nach denen etwas zu verrichten ist und Prozesse die Instanzen, die letztlich die Arbeit verrichten.

Wann immer im System sich etwas dreht, dann ist ein Prozess am werkeln und selbst wenn der Prozessor scheinbar ruht, ist ein Prozess - der Idle-Prozess - aktiv und tut nichts anderes, als zu warten, dass sich wieder etwas tut.

So ein Prozess im System steht nicht nur für sich allein, sondern ist in die Gesellschaft von seinesgleichen integriert, mit denen er auch Informationen austauschen kann.

Die dabei grundlegende Beziehung ist die Eltern-Kind-Verwandtschaft zwischen einem Prozess und den von ihm erzeugten Prozessen.

Der Ursprung aller Prozesse und »Prozessfamilien« liegt im init-Prozess, der als erster Prozess beim Start des Systems mit der Prozessnummer (PID) 1 ins Leben gerufen wird, und dann die elementaren Programme des Systems startet.

Wenn man alle im System laufenden Prozesse auf Basis dieser Beziehung betrachtet, erhält man einen Prozessbaum. Die Hierarchie lässt sich z.B. mit dem Kommando pstree darstellen:

pstree
 init-+-actived
      |-atd
      |-cron
      |-in.identd---in.identd---5*[in.identd]
      |-inetd
      |-innd-+-archive
      |      |-controlchan
      |      |-nnrpd
      |      `-overchan
      |-kdm-+-X
      |     `-kdm---fvwm2-+-FvwmButtons
      |                   |-FvwmPager
      |                   |-netscape---netscape
      |                   |-xosview.bin
      |                   |-xterm---tail
      |                   |-xterm---bash-+-bash1
      |                   |              `-objectman
      |                   |-2*[xterm---bash]
      |                   |-xterm---bash-+-su---bash
      |                                  `-xterm---bash
      |-kflushd
      |-klogd
      |-kpiod
      |-kswapd
      |-kupdate
      |-lockd---rpciod
      |-login---sh

Was ist ein Prozess?

Ein Stück Programm-Code, das zur Ausführung in den Hauptspeicher geladen wurde, und im System durch Parameter wie Prozessnummer (PID), Elternprozessnummer (PPID), Besitzer, Priorität, Nice-Level, Status usw. gekennzeichnet ist. Einige Parameter bringt das Kommando ps zum Vorschein:

ps -ef | head
 UID      PID  PPID  C STIME TTY        TIME CMD
 root       1     0  0 May24 ?      00:00:03 init [3]
 root       2     1  0 May24 ?      00:00:02 [kflushd]
 root       3     1  0 May24 ?      00:00:00 [kupdate]
 root       4     1  0 May24 ?      00:00:00 [kpiod]
 root       5     1  0 May24 ?      00:00:11 [kswapd]
 root       6     1  0 May24 ?      00:00:00 [md_thread]
 bin       90     1  0 May24 ?      00:00:00 [portmap]
 root      98     1  0 May24 ?      00:00:06 /usr/sbin/scanlogd
 root     104     1  0 May24 ?      00:00:01 /usr/sbin/syslogd

Die PID (Prozessnummer) ist die eindeutige Kennzeichnung eines Prozesses während der Laufzeit des Systems, PPID ist die Prozessnummer seines Elternprozesses und UID (Nutzerkennung) der den Prozess startende Benutzer.

Wichtig zu wissen ist, dass ein Prozess, dessen Elternprozess nicht mehr existiert, automatisch dem init-Prozess (PID=1) zugeordnet wird. Die Priorität (C) ist ein während der Laufzeit der Prozesses dynamisch bestimmter Wert, der für die Zuteilung von CPU-Zeit verwendet wird.

Des Weiteren sehen wir bei der Ausgabe von ps die Startzeit STIME, das mit dem Prozess verbundene Terminal TTY (in obigem Beispiel sind allerdings nur Prozesse dargestellt, die keine Ausgaben auf ein Terminal tätigen; diesen Sachverhalt kennzeichnet das Fragezeichen) und den Namen der Programme, die von den Prozessen ausgeführt werden.

Wie wird eine Prozess generiert

und wie sieht sein weiterer Weg aus?

Die beiden wesentlichen Aktionen bei der Prozessentstehung sind die Systemaufrufe fork() und exec(). Mittels fork() wird ein neuer Prozess erzeugt, der zunächst dasselbe Programm wie sein Elternprozess ausführt.

Erst mit dem Aufruf von exec() wird ein Prozess das alte Programm durch ein neues ersetzen und dessen Ausführung beginnen.

Der exec() Aufruf hat seinen Weg auch in den Funktionsumfang der in die Shell eingebauten Kommandos gefunden:

exec ls

login:

Erklärung

Im Beispiel wurde das Programm des laufenden Prozesses durch das Kommando ls ersetzt.

Da der aktive Prozess die Shell selbst ist, wird diese beendet und nachdem nun auch ls seine Tätigkeit abgeschlossen hat, finden wir uns auf der Login-Konsole wieder (sofern es sich um die Login-Shell selbst handelte).

fork() existiert nicht als eigenständiges Kommando. Eine Shell wird diesen Systemruf immer tätigen, um ein Programm innerhalb eines neuen Prozesses auszuführen.

Eine Shell vermag (fast) beliebig viele Prozesse zu starten, jedoch wartet sie in den häufigsten Fällen auf die Terminierung des zuletzt gestarteten Prozesses:

sleep 100

# 100 Sekunden verstreichen, die Shell wartet...

Uns als Anwender steht es nun zu, einem Prozess zu signalisieren, dass er sich z.B. regulär beenden [Ctrl]-[D] , ist i.A. programmabhängig) oder seine Verarbeitung abbrechen ([Ctrl]-[C]) soll:

cat
 Die Eingabe muss mittels [Ctrl]-[D] beendet[Enter]
 Die Eingabe muss mittels [Ctrl]-[D] beendet
 oder mit [Ctrl]-[C] abgebrochen werden[Enter]
 oder mit [Ctrl]-[C] abgebrochen werden
 [Ctrl]-[C]

Anmerkung

'Das reguläre Beenden eines Prozesses kann auf verschiedenen Wegen erfolgen. '

In obigem Beispiel ist das Programm cat eigentlich dazu gedacht, aus einer Datei zu lesen, und beendet sich, sobald das Dateiende erreicht ist.

Wird jedoch von der Standardeingabe eingelesen, und ist diese wie in diesem Fall mit der Tastatur verbunden, so muss der Nutzer dem Programm signalisieren, dass das »Dateiende« erreicht wurde.

Dies erfolgt mit dem End-of-File-Zeichen (kurz EOF), das auf der Tastatur mit der Tastenkombination [Ctrl]-[D] generiert wird.

In solchen Fällen bestünde keine Möglichkeit, beliebig viele Prozesse quasi-parallel zu starten, da der soeben initiierte Prozess die Shell für weitere Eingaben blockiert.

Die Lösung des Problems liegt im Verschieben des Prozesses in den Hintergrund.

Dabei wird er von der Ein- und Ausgabe der Shell abgekoppelt und läuft im Hintergrund weiter, bis er sich selbst beendet, oder aber auf Grund einer notwendigen Interaktion mit dem Benutzer zum Anhalten gezwungen ist.

# Start eines Hintergrundprozesses, der keine Eingaben erwartet

ls -lR > /dev/null &
[1] 706
"beliebiges Arbeiten auf der Kommandozeile" [Enter]
[1]+  Done          ls $LS_OPTIONS -lR >/dev/null
user@sonne>
# Start eines Hintergrundprozesses, der Eingaben erwartet
(ls -Rl >/dev/null; cat)&
[1] 720
[Enter]

[1]+  Stopped       (ls $LS_OPTIONS -Rl >/dev/null; cat)
fg
(ls $LS_OPTIONS -Rl >/dev/null; cat)
hallo[Enter]
hallo
[Ctrl]-[D]

Jedes im Hintergrund laufende Programm wird als Job bezeichnet.

Nach Beendigung der Eingabe des Kommandos mit [Enter] gibt die Bash auf der Standardfehlerausgabe eine Zeile mit Jobinformationen aus, wie am Beispiel zu erkennen ist.

Diese beinhaltet in eckigen Klammern eine fortlaufende, von der Shell vergebene Jobnummer und die vom System dem Prozess zugeordnete Prozessnummer (PID).

Mit dem Kommando jobs kann man Informationen über die derzeit auf einer Shell laufenden Hintergrundprozesse erlangen:

cat &
 [1] 1343
 
 [1]+  Stopped            cat
 
 time dd count=1000000 if=/dev/zero of=/dev/null &
 [2] 1346
 jobs
 [1]+  Stopped            cat
 [2]-  Running            time dd count=1000000 if=/dev/zero of=/dev/null &
 1000000+0 Records ein
 1000000+0 Records aus
 
 real    0m13.817s
 user    0m9.430s
 sys     0m4.040s
 [2]-  Done               time dd count=1000000 if=/dev/zero of=/dev/null
 exit
 exit
 There are stopped jobs.
 jobs
 [1]+  Stopped            cat
 exit
# Shell wurde beendet

Ohne direkten Kontakt

Die bisher vorgestellten Fälle betrachteten nur die Möglichkeit, Programme während einer Sitzung parallel von einer Shell aus zu starten, und im Hintergrund ablaufen zu lassen.

Interessant ist aber auch der Weg, Programme auf der Shell zu starten, und diese nach dem Abmelden, sprich dem Beenden der benutzten Shell, weiter laufen zu lassen.

Bisher waren in allen Beispielen die gestarteten Programme an die aufrufende Shell gebunden. So dass bei Beendigung selbiger auch die an sie gebundenen Prozesse den Aufruf zum Beenden erhalten.

Um Programme von der Shell abzukoppeln, wird das Kommando nohup verwendet.

Dieses schirmt das Programm vom HUP-Signal der Shell ab, so dass es nach dem Beenden der Shell unabhängig weiter laufen kann:

nohup ls -lR / >/dev/null &
 [1] 2511
 ps -ef | grep 2511
 user     2511  2502 20 00:28 tty5    00:00:02 ls -lR /
 user     2514  2502  0 00:28 tty5    00:00:00 grep 2511
 exit
 
 ...auf einer anderen oder neuen Shell:
 Have a lot of fun...
 ps -ef | grep 2511
 user     2511     1 14 00:28 ?       00:00:05 ls -lR /
 user     2524  2516  0 00:29 tty5    00:00:00 grep 2511

nohup startet das Programm nicht selbstständig im Hintergrund.

So ist es möglich, ein Programm analog zum »normalen« Vorgehen (ohne »nohup«) zu starten, eventuell notwendige Eingaben vorzunehmen und erst im Anschluss das Programm durch Eingaben von [Ctrl]-[Z] und nachfolgendem bg in den Hintergrund zu schicken.

Erst jetzt existiert der das Programm ausführende Prozess tatsächlich abgenabelt von seinem Vorfahren.

Ein Prozess, der keine Eingaben benötigt, lässt sich bequem durch ein der Kommandozeile nachgestelltes & unverzüglich vom Elternprozess entkoppeln.

Und welche Möglichkeiten bleiben mir nun, um solch einen Prozess nachträglich zu beeinflussen?

Eine direkte Verbindung zum Terminal wie bei fg ist nicht mehr möglich. Hier hilft nur noch eine indirekte Kommunikation über Signale, die u.a. mit dem Kommando kill übermittelt werden können:

dd if=/dev/zero of=/dev/null &
 [1] 20098
 
 ps -axuw | grep 20098
 user    20098 30.5  0.3  1204  448 pts/4    R    11:49   0:36 dd if=/dev/zero of=/dev/null
 kill -19 20098
 ps -axuw | grep 20098
 user    20098 75.9  0.3  1204  448 pts/4    T    11:49   1:01 dd if=/dev/zero of=/dev/null
 kill -18 20098
 ps -axuw | grep 20098
 user    20098 55.5  0.3  1204  448 pts/4    R    11:49   1:54 dd if=/dev/zero of=/dev/null
 kill -15 20098

Erläuterung

Das Kommando »dd« (zum »Low-Level«-Kopieren) wird im Hintergrund gestartet. Dass es aktiv ist, bestätigt das »R« (running) in der Ausgabe des Kommandos ps. In einer weiteren Eingabe wird dem Prozess die Aufforderung zum Stoppen signalisiert (Signal Nr. 19).

Dass es tatsächlich funktioniert hat, beweist nun das »T« (traced oder gestoppt) in der »ps«-Ausgabe.

Mit dem Signal 18 schließlich wird der Prozess reaktiviert; das »R« ist wieder in der Ausgabe zu sehen.

Damit unser Beispielkommando nicht für alle Zeit die Nullen in den Mülleimer befördert, brechen wir es mit dem Signal 15 (Aufforderung zum Beenden) ab.

Entstehen und Vergehen

Ein Prozess entsteht, indem ein Elternprozess mittels des Systemrufes fork() einen neuen Prozess erzeugt (Ausnahme ist init, der einzige "von Hand generierte" Prozess). Dieser Kindprozess teilt sich alle Ressourcen mit dem Elternprozess, wesentliche Unterschiede sind nur ein eigener Stack und eine eigene PID.

Anhand des Rückgabewertes von fork() ist es den beiden Prozessen nun möglich, zu unterscheiden, ob es sich um den Vorfahren oder einen Nachkommen handelt.

In Abhängigkeit hiervon wird nun ein Kindprozess mittels des Systemrufes exec() ein neues Programm laden.

Irgendwann wird ein Kindprozess seine Arbeit beenden und signalisiert diesen Zustand seinem Elternprozess durch eine entsprechende Nachricht.

Obwohl der Kindprozess bereits jetzt aus Speicher und Prozesstabelle entfernt ist, muss dieses Signal noch verarbeitet werden. Für gewöhnlich zeichnet der Elternprozess dafür verantwortlich.

Zwei Situationen könnten den "normalen Werdegang" durcheinander bringen:

Der Elternprozess ist andersweitig beschäftigt (befindet sich im Zustand D o.a.).

In einem solchen Fall symbolisiert der Zustand Z das noch zu behandelnde Signal. Genau genommen durchläuft jeder Kindprozess die Laufbahn eines Zombies (Zeitspanne zwischen Ableben und Signalbehandlung), jedoch ist sie meist von so kurzer Dauer, dass man gar nichts davon mitbekommt.

Der Elternprozess existiert nicht mehr (Programmfehler o.a.). Jetzt ist der init-Prozess für der Signalbehandlung verantwortlich

Prozesse kontrollieren

Prozessstatus (ps)

ps [Optionen]

(process status) zeigt die Prozesse mit ihrem Status an

Optionen

a	zeigt alle aktive Prozesse
c	zeigt den Namen des Kommandos
l	langes Format
m	zeigt Speichernutzung
r	zeigt nur die laufenden Prozesse
u	zeigt die Besitzer und Startzeit der Prozesse
w	breite Ausgabe, lange Zeilen werden nicht abgeschnitten
x	zeigt Prozesse, die von keinem Terminal kontrolliert werden
S	addiert die Prozessorzeit der Kindprozesse zu den Eltern
tTTY	> kontrolliert werden

Bedeutung der Spalten

COMMAND	der Name des Kommandos; Prozesse, die komplett in den Swapbereich ausgelagert sind, werden in Klammern angezeigt
TIME	die verbrauchte Rechenzeit (Summe User- und Kernelmodus) im Format MM:SS
TTY	die Nummer des kontrollierenden Terminals
UID	die Benutzer-ID des Eigentümers dieses Prozesses
PID	die Prozessnummer dieses Prozesses
PPID	die Prozessnummer des Elternprozesses
PRI	Priorität
TPGID	die Prozessgruppe, der z. Z. das kontrollierende Terminal zu diesem Prozess gehört
SID	die Session-ID des Prozesses (ID der Login-Shell)
STAT	ist der Status des Prozesses; folgende Symbole sind möglich:
	R	lauffähig
	S	schlafend
	W	nicht mehr im Arbeitsspeicher

Prozessbaum (pstree)

pstree     [-a] [-c] [-h|-Hpid] [-l] [-n] [-p] [-u] [-G|-U] [pid|user]

Das Kommando stellt die aktiven Prozesse in einer Baumstruktur dar, welche die Prozessvererbung symbolisiert.

Beispiel

pstree
 init-+-actived
      |-atd
      |-cron
      |-gpm
      |-httpd---httpd
      |-in.identd---in.identd---5*[in.identd]
      |-inetd
      |-kflushd
      |-klogd
      |-kpiod
      |-kswapd
      |-kupdate
      |-lockd---rpciod
      |-2*[login---bash---ssh]
      |-login---sh
      |-2*[mingetty]
      |-nscd---nscd---5*[nscd]
      |-portmap
      |-syslogd

Das Beispiel verdeutlicht, dass init der Elternprozess aller Prozesse ist. pstree versucht per Voreinstellung identische Prozesse in der Darstellung zusammen zu fassen, so bedeutet 2*[mingetty], dass 2 Prozesse das Kommando mingetty ausführen.

Mit der Option -c wird diese Zusammenfassung abgeschaltet:

...

 |-in.identd---in.identd-+-in.identd
     |                       |-in.identd
     |                       |-in.identd
     |                       |-in.identd
     |                       `-in.identd
...

Taskmanager (top)

top [-] [d delay] [q] [c] [S] [s] [i] [n] [b]

top listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf.

Nach Voreinstellung wird diese Liste aller 5 Sekunden aktualisiert, mit der Option -d Zeit kann ein anderes Intervall eingestellt werden.

Eine Option -q lässt das Kommando die Liste so oft wie möglich aktualisieren, mit -n Anzahl kann die Anzahl der Refreshes eingeschränkt werden. Anschließend wird top seine Arbeit beenden.

Als Überschrift zeigt top die Uptime, die Anzahl der Prozesse, eingeteilt nach ihrem Status, die Auslastung von CPU, Speicher und Swap an. Es folgen die Informationen zu den einzelnen Prozessen (die Auflistung enthält nur die Beschreibung der Standard-Informationen)

PID	Prozessnummer
USER	Nutzer, mit dessen Rechten der Prozess ausgeführt wird
PRI	Priorität, mit der der Prozess läuft
NI	Der nice-Faktor, mit dem der Prozess läuft
SIZE	Speichergröße des Prozesses inklusive Stack
RSS	Verbrauch an physischen Speicher
SHARE	Größe des Speichers, der auch von anderen Prozessen genutzt wird
STAT	Status des Prozesses
LIB	Speicherverbrauch der Bibliotheken des Prozesses (bei ELF-Prozessen wird diese Größe mit bei SHARE aufgeschlagen)
%CPU	Verbrauchte CPU-Zeit im letzten Refresh-Intervall (in Prozent)
%MEM	Speicherverbrauch (in Prozent)
COMMAND	Kommando, das der Prozess ausführt.

Interaktive Arbeit mit top

Während das Kommando in periodischen Abständen das Terminal mit neuen Informationen überschwemmt, lassen sich verschiedenste Aktionen vornehmen.

Folgende Eingaben (Auswahl) bewirken folgende Reaktion:

[Leertaste]	Sofortige Aktualisierung der Anzeige
f	Hierüber kann die Anzeige der Informationen eingestellt werden. Es erscheint eine Auflistung aller Informationsfelder, wobei ausgewählte Felder mit einem Stern * gekennzeichnet sind. Vor jedem Feld steht ein Bezeichner (Buchstabe), durch dessen Eingabe die Auswahl umgeschalten wird. Rückkehr zur Ausgabe von top durch [Enter].
h bzw. ?	Anzeige einer Kurzhilfe zu den verschiedenen Kommandos
k	Zum Senden von Signalen an einen Prozess. Es wird zur Angabe der PID und des zu sendenden Signals aufgefordert.
n bzw. #	Zum Ändern der Anzahl angezeigter Prozesse. Man wird zur Eingabe der neuen Anzeige aufgefordert.
o	Ändern der Reihenfolge der Darstellung der Felder. In der oberen Zeile der erscheinenden Ausgabe ist die Reihenfolge symbolisch dargestellt, wobei ein gewähltes Feld durch einen Großbuchstaben markiert ist. Durch Eingabe des entsprechenden Feldbezeichners als Kleinbuchstabe, wird der Eintrag in der Liste "nach hinten" befördert; mittels des Großbuchstaben nach vorn. Rückkehr zur Ausgabe von top durch [Enter] Current Field Order: bAcDgHIjklMnoTPrqsuzVYEFWX Upper case characters move a field to the left, lower case to the right * A: PID = Process Id B: PPID = Parent Process Id C: UID = User Id * D: USER = User Name * E: %CPU = CPU Usage * F: %MEM = Memory Usage G: TTY = Controlling tty * H: PRI = Priority * I: NI = Nice Value ...
r	Ändern der Priorität eines Prozesses
q	Beendet top

nice - Prozess mit anderer Priorität

nice [OPTION]... [COMMAND [ARG]...]

Ein zu startendes Kommando kann durch nice eine andere als die voreingestellte Priorität gegeben werden. D.h. im Vergleich zur "normalen Priorität" erhält ein solcher Prozess prozentual weniger/mehr Rechenzeit zugeteilt.

Ein Wert von -20 bedeutet dabei die höchste Priorität; ein Wert von 20 die geringste.

Ein normaler Nutzer darf die Priorität eines Prozesses nur verringern (also den Wert erhöhen), nur Root kann diese erhöhen (den Wert verringern).

Beispiel

nice -n 19 gcc bigprogram.c
 root@sonne> nice -n -10 inetd

Mit renice kann die Priorität eines laufenden Prozesses beeinflusst werden.

renice - Prozesspriorität ändern

renice priority [[-p] pid ...] [[-g] pgrp ...] [[-u] user ...]

Prozessen kann mittels renice nachträglich eine andere Priorität zugeteilt werden. Wie auch bei nice gilt, dass einzig Root die Priorität erhöhen darf.

Beispiel

renice +10 23258
 23258: Alte Priorität: 0, neue Priorität: 10
 renice -10 23258
 renice: 23258: setpriority: Keine Berechtigung

Das Kommando erlaubt das gleichzeitige Verändern der Prioritäten mehrerer Prozesse. Mögliche Angaben sind: Mehrere Process-IDs, -g GID Die Gruppennummer von Prozessen, -u Nutzer Der Besitzer der Prozesse

nohup - Prozess abnabeln

nohup    COMMAND [ARG]...

Das von nohup gestartete Kommando läuft unabhängig von der aktiven Shell. D.h. ein so gestartetes Kommando arbeitet auch nach dem Beenden der Sitzung (logout) weiter.

Die Ausgaben von nohup werden ggf. in eine Datei nohup.out umgeleitet. Kann diese im aktuellen Verzeichnis nicht erzeugt werden, wird sie im Heimatverzeichnis angelegt.

Scheitert auch dies, beendet nohup seine Tätigkeit.

Ein über nohup gestartetes Kommando erhält eine um 5 erhöhte Priorität.

bash
 ./sleepproc&
 [1] 776
 exit
 ps eax | grep spleepproc
 user@sonne>
 bash
 nohup ./sleepproc&
 [1] 786
 exit
 ps eax | grep spleepproc
 786 ? S N 0:00 sh ./sleepproc...

Anmerkung

Im Beispiel wird in einer Subshell ein Skript "sleepproc" gestartet und die Shell beendet.

Wie zu erwarten war, wurde der in der Shell gestartete Prozess mit dem Ende der Shell beendet.

In einem zweiten Schritt wird das Skript "sleepproc" unabhängig von der Shell gestartet... es existiert auch nach Beendigung der Shell weiter.

Configuration reload

A typical example of a system service is the Apache HTTP server. This consists of a set of background processes (daemons) which are started when the machine boots and stopped when it is shut down. The operation of the service is governed by a set of configuration files which are read when the service is started.

Changes made to the configuration of a service do not necessarily take effect immediately: it may be necessary for a SIGHUP to be sent, or for the relevant processes to be killed then restarted.

At the time of writing (January 2011) there are two mechanisms in common use for managing system services: System V-style init scripts and Upstart. Most of the major GNU/Linux distributions are in the process of migrating from the former to the latter.

Determine the name of the service

Every service has a name that is used to identify it. This is not necessarily the same as the name of the package from which it was installed, or any of the background processes it may spawn. Different distributions may choose different names for the same service.

The following table lists the names used by Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) and SUSE (11.3) for some of the services you are most likely to encounter:

Service	Debian	Ubuntu	CentOS	SUSE
Apache	apache2	apache2	httpd	apache2
BIND	bind9	bind9	named	named
cron	cron	cron	crond	cron
CUPS	cups	cups	cups	cups
DHCP	dhcp3-server	dhcp3-server	dhcpd	dhcpd
(X)inetd	openbsd-inetd	openbsd-inetd	xinetd	xinetd
MySQL	mysql	mysql	mysqld	mysql
NFS	nfs-kernel-server	nfs-kernel-server	nfs	nfs
NTP	ntp	ntp	ntpd	ntp
PostgreSQL	postgresql-8.3	postgresql-8.4	postgresql	postgresql
SSH	ssh	ssh	sshd	sshd
(r)syslog	rsyslog	rsyslog	syslog	syslog

If you know the name of the package that provides the service then you can find the service name by listing the files in that package and searching for ones with a pathname starting with /etc/init.d/, /etc/rc.d/init.d/ or /etc/init/.

On Debian-based systems this can be done using dpkg, for example:

dpkg --listfiles openssh-server | grep "/init"

and on Red Hat-based systems using rpm:

rpm -ql openssh-server-4.3p2 | grep "/init"

'Be aware that the top-level package used to install the service may not be the one that contains the control script: it could be provided by a dependency. '

If you do not know the package name then you could try searching /etc/init.d and /etc/init for a likely-looking filename.

Optionally, validate the new configuration

Some services provide a means to validate the configuration before loading it. This is highly desirable when running a mission-critical server, because if an error is encountered while loading then you may be left with no service until it is fixed.

The method for requesting validation will depend on the software in question, if it is available at all. For Apache on Debian-based systems you can use the apache2ctl command:

apache2ctl -t

Forcibly reload the configuration

If the service command is available then use it to forcibly reload the configuration. For example, if you have determined that the service name is apache2:

service apache2 force-reload

Otherwise, invoke the init.d script directly:

/etc/init.d/apache2 force-reload

The meaning of force-reload is that the configuration should be reloaded without restarting the service if possible, but with a restart if necessary. It is preferable to reload or restart because:* reload will fail if it cannot be achieved without restarting the service.

restart should work for any well-behaved service, but it causes a short period of downtime which may be unnecessary.

Troubleshooting

The service cannot be stopped

If force-reload equates to restart then the control script will need to kill any running processes before starting new ones. Sometimes this fails, in which case you will need to identify and kill the running processes yourself.

Most likely the control script will have attempted a graceful termination using SIGTERM. It is worth trying that again, in case the script did not send the signal for some reason:

killall apache2

Be patient waiting for processes to exit, because some (such as Squid) can take tens of seconds. However if it is clear that SIGTERM has not worked then you can issue a SIGKILL with a clear conscience:

killall -KILL apache2

The service does not restart

This probably indicates an error in the configuration file. Alternative possibilities include:* failure to stop the service, or

leaving a socket in the TIME_WAIT state.

A well-written init script should check that a process has died after sending it a SIGTERM, but some do not. If the service listens on a specific port number (as most do) or needs to exclusively lock files then failure to terminate the old instance will prevent a new instance from starting.

Even if the previous instance has stopped, if it has left a server socket in the TIME_WAIT state then it may still prevent a new instance from starting for a short period (typically 2 minutes on Linux).

The condition occurs when the server terminates an active connection (gracefully or otherwise). Servers can be written to disregard TIME_WAIT, but not without risk. Some do this, some do not.

Alternatives

Reboot the machine

It should rarely be necessary to reboot a machine running GNU/Linux, and it certainly isn't necessary to perform the task described here. However there is one advantage to rebooting after a configuration change: it provides assurance that the changes you have made are persistent, and will not break unexpectedly when a reboot is eventually needed.

Signal the process directly

If a daemon supports reloaded without restarting then the conventional method for signalling this is to send a SIGHUP, for example:

kill -HUP 29964

Do not assume that SIGHUP necessarily has this meaning: in principle it could do anything. You should also exercise caution if there are several copies of the server process running. For example, sending SIGHUP to all copies of sshd would cause one of them to reload the configuration file and the others to terminate the active connections they were handling.

Interprozesskommunikation

Signale sind eine Möglichkeit zur Interprozesskommunikation. Vom Kernel verwendet, dienen sie dazu, Prozesse über bestimmte Ereignisse zu informieren; der Nutzer bedient sich ihrer, um hängen gebliebene Prozesse abzubrechen oder diese anzuweisen, ihre Konfigurationsdateien neu einzulesen.

Die Nutzersignale unterliegen bestimmten Restriktionen, sie dürfen nur an dem Nutzer zugeordnete Prozesse versandt werden. Nicht einmal root hat dem init-Prozess etwas zu sagen.

Signal	Nummer	Aktion
SIGHUP	1	Terminal-Hangup, bei Dämonen verwendet, um ein erneutes Einlesen der Konfigurationsdateien zu erzwingen
SIGINT	2	Tastatur-Interrupt
SIGQUIT	3	Ende von der Tastatur
SIGILL	4	Illegaler Befehl
SIGABRT	5	Abbruch-Signal von abort(3)
SIGFPE	8	Fließkommafehler (z.B. Division durch Null)
SIGKILL	9	Unbedingte Beendigung eines Prozesses
SIGSEGV	11	Speicherzugrifffehler
SIGPIPE	13	Schreiben in eine Pipe, ohne dass ein Prozess daraus liest
SIGTERM	15	Prozess soll sich beenden (default von kill)
SIGCHLD	17	Ende eines Kindprozesses
SIGCONT	18	Prozess fortsetzen
SIGSTOP	19	Prozess anhalten
SIGSTP	20	Ausgabe wurde angehalten
SIGUSR1	30	Nutzerdefiniertes Signal

Die genaue Zuordnung zwischen symbolischem Signal und Nummer ist in Linux in der Datei

/usr/include/linux/asm/signal.h

zu finden.

Zum manuellen Versenden von Signalen dienen die beiden Kommandos kill und killall. kill erwartet im Argument die ID des Prozesses, während killall den Namen des Programms verlangt.

Beide Kommandos verstehen die Signalangabe in numerischer (1 für SIGHUP,..., 9 für SIGKILL,...) als auch in symbolischer (HUP für SIGHUP,..., KILL für SIGKILL,...) Form.

Als Beispiel nehmen wir an, der "Netscape" reagiere nicht mehr (was leider keine hypothetische Annahme darstellt). Also werden wir den entsprechenden Prozess per Hand beenden:

# mittels killall auf die höfliche Tour

killall -15 netscape

# reagiert Netscape immer noch nicht, dann auf die harte Tour
killall -KILL netscape

# mittels kill
ps ax | grep netscape    
887 tty1     S      2:12 /opt/netscape/netscape
kill -9 887

Prozesse beenden mit kill

kill·[-s Signal]·[-p]·[-a]·[-l·[Signalnummer]]· Prozess-ID ...

beendet außer Kontrolle geratene („aufgehängte“) Prozesse und sendet Signale an Prozesse.

Das Signal kann mit Namen oder Nummer angegeben werden. Ist kein Signal angegeben, wird SIGTERM (15) gesendet.

Der Prozess wird kann durch seine Prozessnummer oder seinen Namen angegeben

Signale können ohne Root-Privilegien nur an die eigenen Prozesse gesendet werden.

Prozesse reagieren unterschiedlich auf diese Signale:# Wenn das Anwendungsprogramm eine Funktion zur Behandlung eines Signals bereitstellt kann dieses Signal abgefangen werden. Signale können damit zur asynchronen Fehler- bzw. Ausnahmebehandlung sowie zu einer primitiven Prozesskommunikation genutzt werden.

Das Signal kann ignoriert werden. Das ist der Regelfall für alle Signale die nicht abgefangen werden.
Die Signale SIGKILL und SIGSTOP können nicht abgefangen werden, sie werden direkt vom Kernel behandelt. Mit SIGKILL (9) wird der Prozess sofort beendet.

Optionen

-s Signal	sendet das Signal anstelle von SIGTERM (15)
-a	veranlasst kill auch Prozesse anderer Benutzer einzubeziehen
-l	gibt eine Namensliste aller Signale aus; eine Signalnummer als Argument wird in den entsprechenden Signalnamen übersetzt

killall - Prozessen Signale senden

killall [-egiqvw] [-signal] name ...

Der wesentlichste Unterschied zum Kommando kill ist die Spezifizierung der Prozesse über den Namen der Kommandos, die sie ausführen oder mittels ihrer Gruppennummer (-g GID).

killall sendet allen Prozessen Signale, die das Kommando ausführen, mit der Option -i kann aber eine nochmalige Rückfrage vor dem tatsächlichen Senden erzwungen werden:

killall -i -15 bash
 Kill bash(280) ? (y/n) n
 Kill bash(350) ? (y/n) n
 Kill bash(351) ? (y/n) n
 Kill bash(352) ? (y/n) n
 bash: no process killed

Mit der Option -w wartet killall so lange, bis der letzte der angegebene Prozess seine Arbeit beendet hat. Das Kommando schickt hierzu periodisch (jede Sekunde) erneut das Signal.

Wiederkehrende Abläufe mit cron

Schon die Standardinstallation von Linux birgt für manchen Benutzer Überraschungen.

Da fährt man nichts ahnend sein System hoch, freut sich auf eine gute Performance und wundert sich, dass die CPU am Limit kreiselt, obwohl man doch nur seine Mails begutachtet.

Geht man der Ursache auf den Grund, findet man heraus, dass »nobody« das Kommando »find« ausführt und sämtliche Ressourcen zu verschlingen scheint.

Wer ist dieser »nobody«? Und wie kommt er dazu, meinen Dateibaum zu durchstöbern?

Erst einmal sei der Leser beruhigt; in jenem Fall ist es unwahrscheinlich, dass sich hinter »nobody« ein arglister Eindringling verbirgt.

Hier ist vermutlich irgend ein Systemprogramm am werkeln, das irgend eine Datenbank aktualisiert.

Und wer rief das Programm?

Mit ziemlicher Sicherheit identifiziert man den cron als den Übeltäter.

Und »Übeltäter« ist für diesen Pünklichkeitsfanatiker sicher die unpassendste Bezeichnung, er verrichtet schließlich nur gewissenhaft die ihm angetragenen Aufgaben.

Beim cron handelt es sich um einen Dämonen, auch wenn sein Name nicht mit dem sonst üblichen »d« endet. Warum dieser Name?

Wer weiß... schieben wir es seinem Entwickler Paul Vixie in die Schuhe. Dieser cron sollte schon während des Systemstarts aktiviert werden.

Fortan wird er minütlich zum Leben erwachen und in seinen Terminkalendern nachschlagen, ob etwas zu erledigen ist.

Wenn nicht, versetzt er sich für eine weitere Minute in den Schlaf.

Der Start des Dämonen

In den meisten Fällen sollte nach der Linuxinstallation der Dämon bereits mit dem Start des Systems aktiv werden.

Die verschiedenen Distributionen regeln das über ein Skript, das in allen Runleveln gestartet wird. Debian speichert das Skript unter »/etc/init.d/cron«, bei RedHat liegt es als »/etc/rc.d/init.d/cron« auf der Platte und SuSE hält »/sbin/init.d/cron« für das richtige Konzept.

Sollte bei Ihnen der cron nicht aktiv sein, so überprüfen Sie, ob in den jeweiligen Runlevel-Verzeichnissen ein Link auf das Skript existiert.

Mit »/usr/sbin/cron« vermag der Systemadministrator den Dämon von Hand ins Leben zu berufen, da dessen Arbeit allerdings von unschätzbarem Nutzen ist, sollten ggf. die fehlenden Links erzeugt werden.

Als Linknamen bieten sich »S21cron« für das Startskript und »K19cron« für das Stoppskript an.

Wo sich die Runlevel-Verzeichnisse befinden und was es mit der Namensgebung auf sich hat, ist Thema des Abschnitts Bootvorgang.

Mehrere Terminkalender

Ist der Geist erst einmal losgelassen, so schaut er als erstes in der Datei »/etc/crontab« nach, welchen Spuk er im System als nächstes zu treiben hat.

Und beim weiteren Vorgehen scheiden sich die Geister...

Hier treiben die verschiedenen Distributionen allerlei eigenen »Unsinn« und kompilieren die verschiedensten Suchpfade in den Code des Dämons ein.

Entsprechend den Richtlinien des Filesystem Hierarchie Standards sollten die benutzereigenen Tabellen im Verzeichnis »/var/spool/cron« angesiedelt sein, bei Debian und RedHat findet man sie unter »/var/spool/cron/crontabs« und SuSE liegt mit »/var/cron/tabs« völlig daneben.

Die letzten Dateien, die zum üblichen Auftragsvolumen des cron gehören, sind »cron.hourly«, »cron.daily«, »cron.monthly« und »cron.weekly«, die distributionsabhängig entweder unterhalb von »/etc/cron.d« oder direkt in »/etc« (SuSE) liegen.

Zu bemerken ist, dass die Dateien nicht existieren müssen, da alle Aufträge für den Dämon auch in einer einzigen Datei enthalten sein könnten.

Und außerdem sind die zu überwachenden Dateien und Pfade durch Herumspielen im Quellcode beliebig anpassbar.

Der Eine darf, der Andere nicht...

Dem Systemadministrator steht es frei, bestimmte Benutzer von den Diensten des cron auszuschließen. Hierzu kann er die Benutzerkennzeichen in die Dateien »allow« und »deny« aufnehmen.

Jeder Benutzer, der in der allow-Datei enthalten ist (ein Benutzer je Zeile), darf eine eigene »crontab« anlegen. Im Falle einer leeren Datei »allow« kann also niemand den cron benutzen.

Existiert die »allow«-Datei nicht, kommt »deny« ins Spiel. Sie enthält genau jene Benutzer, denen der Dienst versagt wird. allow und deny sind hier nur beispielhafte Bezeichnungen für die Dateien. SuSE und Debian benennen sie tatsächlich so, im ersten Fall liegen sie im Verzeichnis »/var/cron« und bei Debian unter »/var/spool/cron«.

RedHat regelt den Zugriff über die beiden Dateien »/etc/cron.allow« und »/etc/cron.deny«.

/etc/crontab

Datei:Grafik7.png

Wie muss nun der Inhalt einer crontab-Datei aussehen?

Eine Zeile, die nicht mit dem Doppelkreuz (»#« - Kommentar) beginnt, ist entweder eine Variablenzuweisung oder eine Anweisung der Art: »Starte das Kommando zur dieser Zeit an diesem Datum«.

Jeder Zeile entspricht einem Eintrag, d.h. eine Anweisung oder Variablenzuweisung darf sich nicht über mehrere Zeilen erstrecken.

Auch ist die Zeile auf 1024 Zeichen begrenzt. Beginnt eine Anweisungszeile mit einem Minus »-«, so wird kein syslog-Eintrag zur Protokollierung des Kommandostarts vorgenommen.

Eine Variablenzuweisung legt Umgebungsvariablen für den cron neu fest. So lassen sich dem Dämon mit PATH alternative Pfade angeben, wo er die Kommandos zu suchen hat.

Mit SHELL kann eine von der »/bin/sh« abweichende Shell zur Kommandoausführung benannt werden und mit MAILTO ist es möglich, die Ausgabe, die der cron per Mail an den Eigentümer der »crontab« ausliefert, einem anderen Benutzer zukommen zu lassen (oder gar zu unterdrücken »MAILTO=«).

Eine Anweisung besteht aus 7 Feldern (in den privaten Tabellen nur 6), wobei diese durch Leerzeichen oder Tabulatoren getrennt sind.

Die ersten 5 Felder betreffen die Angabe des Zeitpunkts, wann das Kommando zu starten ist:

Feld 1: Minute	0-59
Feld 2: Stunde	0-23
Feld 3: Tag	0-31
Feld 4: Monat	0-12, jan, feb, ..., dec
Feld 5: Wochentag	0-7, sun (entspricht 0 oder 7), mon, ..., sat

Jedes Feld erlaubt auch die Eingabe mehrerer Werte.

Die nachfolgende Tabelle fasst die verschiedenen Syntaxvarianten zusammen, die Beispiele beziehen sich auf Minuten:

	Syntax	Beispiel/Bemerkung
Voller Bereich	*	0, 1, 2, ..., 59
Ausgewählte Bereiche	1-5	1, 2, 3, 4, 5
Liste	2,3,11,12	Nur an den angegebenen Werten
	2,3,30-40	Kombination aus Liste und Bereich
Schrittweite	*/2	aller zwei Minuten (0, 2, ..., 58)

Tag, Wochentag und Monat können auch als englische Namen (die ersten drei Buchstaben) angegeben werden.

Klein- und Großschreibung werden dabei nicht unterschieden. Bereiche sind bei der Verwendung von Namen nicht erlaubt.

Die Datei »/etc/crontab« enthält nun als 6. Feld den Benutzer, in dessen Auftrag das Programm auszuführen ist.

Bei allen anderen Tabellen entfällt der Eintrag, da die enthaltenen Kommandos immer mit den Rechten des Eigentümers der Datei gestartet werden.

Das letzte Feld beinhaltet in jeder »crontab« das auszuführende Kommando.

Ein Prozentzeichen »%« kann benutzt werden, um einen Zeilenumbruch zu simulieren, alle folgenden Daten werden dem Kommando als Argumente übergeben.

Die Datei »/etc/crontab« könnte wie folgt ausschauen:

root@sonne> cat /etc/crontab
 SHELL=/bin/sh
 PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
 MAILTO=root
 # Langwierige Jobs sollten besser Nachts ausgeführt werden...
 # Um 21.00 Uhr soll die Warteschlange der Faxe bearbeitet und geleert werden
  0 21 * * *    root  test -x /usr/sbin/faxqclean && /usr/sbin/faxqclean
 # Reports über das Faxgeschehen sind um 23.25 Uhr zu generieren
 25 23 * * *    root  test -e /usr/sbin/faxcron && sh /usr/sbin/faxcron | mail FaxMaster
 
 # check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
 #
 # Das nächste Kommando soll aller 15 Minuten starten und nicht protokolliert werden
 -*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
 # 0.00 Uhr jeden Tag
  0 0  * * *     root  rm -f /var/cron/lastrun/cron.daily
 # 0.00 Uhr jeden Sonntag
  0 0  * * 6     root  rm -f /var/cron/lastrun/cron.weekly
 # 0.00 Uhr jeden ersten Tag im Monat
  0 0  1 * *     root  rm -f /var/cron/lastrun/cron.monthly

Benutzereigene crontab

Bei all der Pingelichkeit mit der Sicherheit in einem Unix-System wird sich niemand darüber wundern, dass Otto-Normalverbraucher seine cron-Jobs nicht direkt in das entsprechende Spoolverzeichnis schreiben kann.

Aus diesem Grund steht ihm das Kommando crontab zur Verfügung.

Dem Systemadministrator steht es zu, die nachfolgenden Optionen mit -u Benutzer zu koppeln und somit die Datei eines beliebigen Benutzers zu bearbeiten.

Die simplen Optionen sind -l zur Anzeige des Inhalts seiner eigenen Tabelle und -r zum Löschen jener. Zum Editieren der Datei ist das Kommando mit der Option -e zu starten. Kommt jetzt die Ausgabe:

crontab -e
 You (user) are not allowed to use this program (crontab)
 Contact your sysadmin to change /var/cronallow or /var/crondeny
 See crontab(1) for more information

...so trete man seinem Systemadministrator entgegen und frage ihn, warum man von der Benutzung des Dienstes ausgeschlossen wurde.

Gesetzten Falls, der Aufruf glückte, so findet man sich in einem Editor wieder.

Welcher das ist, steht in den Shellvariablen $VISUAL und $EDITOR (nur wenn erstere nicht gesetzt ist, wird die 2. ausgewertet) und kann nach persönlichen Wünschen angepasst werden.

Übrigens scheitert ein Kommandoaufruf auch, wenn die Variable nicht oder auf einen nicht installierten Editor gesetzt ist.

Beispiel

Einmal pro Woche (Mittwoch) sollten wir ein Backup unseres Heimatverzeichnisses in Erwägung ziehen.

Wir archivieren also alle Dateien und schicken das Archiv per Mail an eine Adresse. Zusätzlich soll die normale Nachricht über die erfolgte Ausführung des Kommandos unterdrückt werden.

crontab -e
 MAIL=
 0 0 * * 3 tar czvf - /home/user | uuencode backup.tgz | mail user@outside.all -s "Backup"

Nach dem Abspeichern der Datei meldet crontab entweder den Vollzug »crontab: installing new crontab« oder aber einen aufgetretenen Fehler.

Wir provozieren einen solchen, indem wir einen Zeilenumbruch angeben:

crontab -e
 */30 14-16 * * 1-5 echo "Feier
 abend"
 Speichern der Datei
 ccrontab: installing new crontab
 "/tmp/crontab.2171":2: bad minute
 errors in crontab file, can't install.
 Do you want to retry the same edit?

crontab weist auf die mögliche Fehlerursache hin (Zeile 2:bad minute).

Klar, dass »abend« keine gültige Minutenangabe ist. Weiterhin verweigert das Kommando das Abspeichern der Datei und bietet ein erneutes Bearbeiten an.

Durch Eingabe von »y« gelangen wir zurück zum Editor.

Job zu bestimmter Zeit starten - at

at     [-V] [-q queue] [-f file] [-mldbv] ZEIT

Mit at lassen sich Kommandos zu einem späteren Zeitpunkt ausführen.

Der Zeitpunkt lässt sich in verschiedenen Formaten angeben:

17:23	17.23 Uhr des heutigen Tages
midnight	0.00 Uhr
noon	12.00 Uhr
teatime	16.00 Uhr
10:30pm	22.30 Uhr, mit dem Suffix am anstatt »pm« 10:30 Uhr
	Am dieses Jahres, alternative Angaben sind und
	Am , alternative Angaben sind und .
Zeitpunkt + Zeitspanne	Als Zeitpunkt kann jede oben beschriebene Angabe stehen und now (»jetzt«), als Zeitspanne kommt ein Wert gefolgt von minutes (Minuten), hours (Stunden), days (Tage) und weeks (Wochen) in Frage.
tomorrow, today	Spezifizieren den Zeitpunkt »Morgen« und »heute«.

at liest die zu startenden Kommandos von der Standardeingabe oder aus einer Datei, falls eine solche mit der Option "-f" angegeben wurde.

Alle Kommandos werden in eine Warteschlange eingereiht, deren Name aus einem einzelnen Buchstaben besteht. Die Voreinstellung "a" kann mit der Option "-q" überschrieben werden.

Die alphabetische Reihenfolge der Queues gibt die Priorität ihrer Bearbeitung vor.

Nach Beendigung eines Jobs versendet at die Ausgaben des Kommandos per Mail (sendmail muss installiert sein!) an den Auftraggeber.

Für Kommandos, die keine Ausgaben erzeugen, kann mit der Option "-m" eine Mail-Benachrichtigung über den erfolgten Abschluss der Bearbeitung erzwungen werden.

at teatime tomorrow
 at> echo "Wieder mal Feierabend"
 at> [Ctrl]-[D] <EOT>
 warning: commands will be executed using /bin/sh
 job 3 at 2000-06-07 16:00
 
 at now +30 weeks
 at> mail -s "Wunschliste" Weihnachtsmann@weissnicht.wo < liste.txt at> [Ctrl]-[D] <EOT>
 warning: commands will be executed using /bin/sh
job 5 at 2001-01-02 09:12

Start des Dämonen

Für die Bearbeitung der Jobs ist der at-Dämon atd verantwortlich, der bereits während des Systemstarts aktiviert werden sollte. Mit Hilfe des Kommandos ps sollte ein Zeichen des Geistes zu erhalten sein:

ps ax | grep atd
   232 ?        S      0:00 /usr/sbin/atd
   518 ?        S      0:00 /usr/sbin/rpc.rstatd
  4316 ?        S      0:00 /usr/sbin/rpc.kstatd
  1967 pts/8    S      0:00 grep atd

Fehlt eine den Dämonen betreffende Zeile, kann dieser von Hand gestartet werden.

Die interessanten Optionen sind hierbei -l Auslastungsfaktor und -b Sekunden. Der atd ist so ausgelegt, dass er einen Auftrag nur zur vereinbarten Zeit startet, wenn die Systemauslastung einen bestimmten Wert (0.8) unterschritten hat.

Ist das System zum Zeitpunkt zu beschäftigt, stellt der atd den Auftrag solange zurück, bis der Lastwert unter die Schranke gefallen ist.

Mit ersterer Option kann ein anderer als der voreingestellte Wert vereinbart werden, dies ist bei Mehrprozessorsystemen zu empfehlen.

Die momentane Auslastung ermittelt der Dämon anhand der Datei »/proc/loadavg«. Mit der zweiten genannten Option kann das Zeitintervall variiert werden, in dem der atd die Auftragswarteschlangen nach fälligen Jobs durchsucht. Voreinstellung ist 60 Sekunden.

Um den Dämonen schließlich nicht immer von Hand starten zu müssen, sollten Sie einen Link in allen Runleveln auf ein entsprechendes Skript anlegen.

Bei den meisten Distributionen sollte das Skript »at« heißen und im Verzeichnis unterhalb der Runlevel liegen.* Debian und RedHat: Verzeichnis /etc/rc.d/init.d

Zugangskontrolle

Der Zugang zum Dienst kann vom Systemverwalter eingeschränkt werden, in dem er die Benutzerkennzeichen in einer der Dateien »/etc/at.allow« oder »/etc/at.deny« aufnimmt.

Dabei wird die zweite Datei nur ausgewertet, falls erstere fehlt. In »at.allow« trägt Root genau die Benutzer ein, die den Dienst beanspruchen dürfen.

Nichterwähnte Benutzer werden somit ausgeschlossen.

Sollen jedoch nur einige wenige Personen ausgenommen werden, so ist es einfacher, diese in der Datei »at.deny« einzutragen.

Alle dort nicht benannten Benutzer haben dann Zugriff auf at. Existiert keine Datei, ist der Dienst für jeden nutzbar.

Jobliste anzeigen (atq)

atq     [-V] [-q queue]

Der Inhalt der Warteschlange ausstehender at-Jobs wird angezeigt.

Sollen nur die Aufträge einer bestimmten Queue betrachtet werden, muss mit der Option "-q" der Name der Warteschlange angegeben werden.

atq
 1 2000-06-06 16:00 a
 3 2000-06-07 16:00 a
 4 2001-01-02 09:07 a
 5 2001-01-02 09:12 a
 6 2000-06-11 10:16 b

Die Informationen sind Jobnummer, Zeitpunkt des Auftrags und Name der Warteschlange. Eine analoge Ausgabe liefert at -l.

Job abbrechen (atrm)

atrm    [-V] job [job...]

Aufträge können anhand ihrer Jobnummer gelöscht werden:

atrm 3 4 5 6
 atq
 1 2000-06-06 16:00 a

at -r arbeitet analog.

Job bei Inaktivität mit batch starten

batch    [-V] [-q queue] [-f file] [-mv] [ZEIT]

Batch arbeitet analog zum Kommando at mit dem einzigen Unterschied, dass batch den Start des Kommandos soweit zurückstellt, bis die Auslastung des Systems eine gewisse Grenze (load average < 0.8) unterschritten hat.

Das Kommando wird man bspw. dazu benutzen, eine langwierige und ressourcenintensive Berechnung erst nach Feierabend zu starten (wenn normalerweise die Rechner nicht mehr benötigt werden).

Sollte aber dennoch ein Kollege Überstunden scheffeln (das soll es wohl geben;-) und den Rechner benutzen, wird die Bearbeitung des Jobs zurückgestellt...

Verwendung und Optionen des Kommandos sind exakt wie bei at beschrieben.