Linux/Prozesse

Prozesse kontrollieren

Prozessstatus (ps)

(process status) zeigt die Prozesse mit ihrem Status an

ps [Optionen]

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)

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

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

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 listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf.

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

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
 
 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.

2.7 Konfiguration neu laden Ein typisches Beispiel für einen Systemdienst ist der Apache-HTTP-Server. Dies besteht aus einer Reihe von Hintergrundprozessen (Daemons), die beim Starten des Computers gestartet und beim Herunterfahren gestoppt werden. Der Betrieb des Dienstes wird durch eine Reihe von Konfigurationsdateien geregelt, die beim Starten des Dienstes gelesen werden. Änderungen an der Konfiguration eines Dienstes werden nicht unbedingt sofort wirksam: Möglicherweise muss ein SIGHUP gesendet oder die entsprechenden Prozesse beendet und anschließend neu gestartet werden. Zum Zeitpunkt des Schreibens (Januar 2011) sind zwei Mechanismen für die Verwaltung von Systemdiensten gebräuchlich: Init-Skripte im System V-Stil und Upstart. Die meisten der wichtigsten GNU / Linux-Distributionen werden derzeit von der ersteren auf die letztere migriert.

Bestimmen Sie den Namen des Dienstes

Jeder Dienst hat einen Namen, mit dem er identifiziert wird. Dies ist nicht unbedingt derselbe wie der Name des Pakets, von dem es installiert wurde, oder eines der Hintergrundprozesse, die es möglicherweise erzeugt. Unterschiedliche Distributionen können unterschiedliche Namen für denselben Dienst auswählen.
In der folgenden Tabelle sind die Namen aufgeführt, die Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) und SUSE (11.3) für einige der Dienste verwenden, auf die Sie am wahrscheinlichsten stoßen:

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

Wenn Sie den Namen des Pakets kennen, das den Dienst bereitstellt, können Sie den Dienstnamen finden, indem Sie die Dateien in diesem Paket auflisten und nach Dateien mit einem Pfadnamen suchen, der mit /etc/init.d/, /etc/rc.d beginnt /init.d/ oder / etc / init /.
Auf Debian-basierten Systemen kann dies mit dpkg erfolgen, zum Beispiel:

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

and on Red Hat-based systems using rpm:

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

Beachten Sie, dass das zur Installation des Dienstes verwendete Paket der obersten Ebene möglicherweise nicht das Steuerungsskript enthält, das möglicherweise von einer Abhängigkeit bereitgestellt wird. '

Wenn Sie den Paketnamen nicht kennen, können Sie versuchen, in /etc/init.d und / etc / init nach einem wahrscheinlich aussehenden Dateinamen zu suchen.

Überprüfen Sie optional die neue Konfiguration

Einige Dienste bieten eine Möglichkeit, die Konfiguration vor dem Laden zu überprüfen. Dies ist sehr wünschenswert, wenn ein geschäftskritischer Server ausgeführt wird. Wenn beim Laden ein Fehler auftritt, bleibt möglicherweise kein Dienst verfügbar, bis dieser behoben ist.
Die Methode zum Anfordern einer Validierung hängt von der jeweiligen Software ab, sofern diese überhaupt verfügbar ist. Für Apache auf Debian-basierten Systemen können Sie den Befehl apache2ctl verwenden:

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 (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

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.