Cron

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Cron and the translation is 65% complete.
Outdated translations are marked like this.
Resources

Dieser Artikel beschreibt, wie Sie einen cron Daemon unter Gentoo Linux einrichten und verwenden können.

Cron Grundlagen

Was cron macht

Cron ist ein Hintergrunddienst, der geplante Aufgaben, die durch das Kommando crontab eingerichtet wurden, abarbeitet. Er erledigt diese Aufgaben, indem er jede Minute aufwacht und überprüft ob es einen Cron-Job gibt, der ausgeführt werden muss.

Hinweis
Beachten Sie, dass crontab sowohl der Name einer Liste von Cron-Jobs, als auch der Name für das Kommando zum Editieren dieser Liste ist.
Hinweis
Wenn das systemd Initsystem-Verwendet wird, sind (persistent) timers ein möglicher Ersatz für (ana)cron.

Der tatsächliche Cron

Es gibt mehrere Cron-Implementierungen in Portage, aus denen Sie wählen können. Jeder dieser Implementierungen stellt die gleiche Schnittstelle, meistens crontab genannt, bereit. Außerdem gibt es eine Implementierung names Anacron, welche für Systeme gedacht ist, die nicht ununterbrochen laufen.

Alle Cron-Pakete sind vom Paket sys-process/cronbase abhängig. Dies ist technisch nicht notwendig, bietet aber Cron-ähnliche Funktionen, die die meisten Nutzer zu schätzen wissen.

Bevor Sie anfangen mit Cron zu arbeiten, müssen Sie sich entscheiden, welche Implementierung Sie nutzen möchten.

Welche Cron-Implementierung ist die richtige?

Hinweis
Installieren Sie virtual/cron, um die Gentoo Standard-Implementierung von Cron zu installieren.

cronie

Cronie (sys-process/cronie) ist eine Abspaltung vom nun veralteten vixie-cron, die von Fedora erstellt wurde und weiterhin gewartet wird. Da es eine Abspaltung ist, hat cronie die gleichen Funktionen wie vixie-cron. Zusätzlich kommt cronie mit einer anacron-Implementierung die standardmäßig mit der USE-Flag anacron eingeschaltet wird. Geben Sie acht auf Konfigurationsabweichungen wie in bug #551352 beschrieben, wenn Sie von einem anderen cron-System migrieren. Eingestellte Aufgaben könnten möglicherweise überhaupt nicht laufen.

dcron (Dillon's Cron)

sys-process/dcron bietet eine einfache, elegante und sichere Implementierung von cron. Es ist nicht erlaubt Umgebungsvariaben in crontabs zu nutzen und alle Cron-Jobs werden von /bin/sh ausgeführt. Wie bei vixie-cron hat jeder Benutzer einen eigenen crontab. Ab der Version 4 enthält es anacron-ähnliche Funktionen.

Funktionen von sys-process/dcron:

  • Schnell, einfach und frei von unnötigen Funktionen;
  • Zugriff auf crontab ist auf die cron-Gruppe beschränk, d.h. es ist nicht auf externe Fakultäten angewiesen.

fcron

sys-process/fcrons Ziel ist es, vixie-cron und anacron zu ersetzen. Es wurde für Systeme entworfen, die nicht ständig laufen und es ist vollgepackt mit extra Funktionen. Es bietet Aufgaben-Starteinschränkungen, Aufgaben-Serialisierungs-Steuerelemente, die Fähigkeit nice-Werte an Aufgaben zu vergeben und die Fähigkeit Aufgaben beim Systemstart auszuführen.

Funktionen von sys-process/fcron:

  • Entwickelt für Systeme, die nicht ständig laufen, d.h. es kann einen Aufgabe nach dem Neustart ausführen, wenn er verpasst wurde;
  • Setzen von Umgebungsvariablen und viele andere Optionen in crontabs;
Verbesserte crontab-Syntax mit Unterstützung für viele neue Funktionen;
  • Jeder Benutzer kann eine persönliche Crontab haben, der Zugriff wird durch cron.allow und cron.deny kontrolliert

bcron

sys-process/bcron ist ein neues cron-System, das mit dem Sicherheitsgedanken im Vordergrund entworfen wurde. Um dies zu erreichen, ist das System in mehrere eigenständige Programme aufgeteilt. Jedes Programm ist für eine Aufgabe zuständig und die Kommunikation untereinander ist streng kontrolliert. Die Benutzeroberfläche ist ein direkter Austausch für ähnliche Systeme (wie vixie-cron), aber das interne unterscheidet sich stark.

Funktionen von sys-process/bcron:

  • Drop-in-Ersatz für vixie-cron;
  • Multiprozess-Design;
  • Eingebaute Sommerzeit-Unterstützung.

anacron

Anacron ist kein Cron-Hintergrunddienst. Es arbeitet in funktionen mit einem Cron-Hintergrunddienst zusammen. Es führt Kommandos in festgelegten Tagesintervallen aus und setzt nicht vorraus, das das System kuntinuierlich läuft. Es führt Aufgaben später aus, wenn das System zur Ausführungszeit ausgeschaltet war. Anacron greift normal auf einen Cron-Hintergrunddienst zurück um seine Aufgaben jeden Tag auszuführen.

Cron benutzen

Installation

Wählen Sie die richtige Cron-Implementierung für den Auftrag aus, und emergen sie dann:

root #emerge --ask dcron

Vergewissern Sie sich, dass der Cron-Daemon Ihrer Wahl zum Init-Prozess des Systems hinzugefügt wurde; ohne diesen Schritt wird der Cron-Daemon seine Aufgabe nicht erfüllen.

root #/etc/init.d/dcron start
root #rc-update add dcron default

Wenn Fcron oder dcron nicht installiert sind, kann es sinnvoll sein, Anacron als Helfer für den Cron-Daemon zu installieren.

root #emerge --ask anacron

Vergessen Sie auch hier nicht, anacron in den Init-Prozess des Systems aufzunehmen.

root #/etc/init.d/anacron start
root #rc-update add anacron default

Für anacron gibt es normalerweise keinen init-Prozess. Stattdessen muss anacron durch eine andere cron-Implementierung gestartet werden.

One method is to launch anacron through a cron definition. By default, it installs an hourly run script, which is consumed by most cron implementations. If that isn't the case though, then it can still be launched through manual definitions:

DATEI /etc/crontabStarten von anacron durch eine Cron-Definition
# Anacron alle 10 Minuten starten
*/10 * * *  root  /usr/sbin/anacron
 
# Alternativ dazu können Sie das von anacron bereitgestellte Skript 0anacron jede Stunde ausführen
# 59 * * * *  root  /etc/cron.hourly/0anacron

System crontab

The post install messages from some of these cron packages instruct the user to run crontab /etc/crontab. The /etc/crontab file is the system crontab. A cron installation can use it in conjunction with sys-process/cronbase to run the scripts in /etc/cron.{daily,hourly,weekly,monthly}. Note that only cronie schedules jobs in /etc/crontab automatically. Dcron users will need to run crontab /etc/crontab every time changes are made to the /etc/crontab file. Fcron users need to run emerge --config sys-process/fcron to configure the system crontab.

Please note that jobs scheduled in the system crontab might not show up in the list of cron-jobs displayed by running crontab -l.

Of course, users can choose not to use any system crontab at all. If dcron or fcron has been chosen, do not run crontab /etc/crontab. If cronie or bcron has been chosen comment all lines in /etc/crontab.

Eine schnelle und einfache Möglichkeit, alle Zeilen in einer Datei auszukommentieren, ist die Verwendung des Befehls sed. Führen Sie den folgenden Befehl aus, um alle Zeilen in etc/crontab auszukommentieren

root #sed -i -e "s/^/#/" /etc/crontab

Vertrauenswürdigen Benutzern Zugang zu cron geben

For users other than root to have access to the cron daemon, read this section, otherwise proceed to the next section.

Hinweis
Giving another user access to crontab does not let him run cron-jobs as root. For a user to be able to edit the root crontab, look into using sudo (app-admin/sudo). Please read the Gentoo Sudo(ers) Guide for more details.

No matter which cron package has been chosen, to allow a user to use crontab he will first have to be in the cron group. As an example, to add the user larry to the cron group run:

root #gpasswd -a larry cron
Hinweis
When adding a user to the cron group, make sure that the user logs out and logs back in for the group change to take effect.

dcron

Wenn Sie dcron verwenden, ist der oben beschriebene Schritt alles was nötig ist, um einem Benutzer zugriff auf crontab zu geben. Dcron-Benutzer können in der nächsten Sektion weitermachen, alle Anderen müssen weiterlesen.

fcron

Wenn Sie fcron verwenden, editieren Sie die Dateien /etc/fcron/fcron.deny und /etc/fcron/fcron.allow. Die sicherste Weise, ein System zu betreiben, ist allen Benutzern in /etc/fcron/fcron.deny den Zugriff zu verbieten und dann explizit per /etc/fcron/fcron.allow den Zugriff für die gewünschten Nutzer zu gewähren.

Wichtig
Wenn weder /etc/fcron/fcron.allow noch /etc/fcron/fcron.deny existieren, dann wird allen Nutzern, die in der cron-Gruppe sind, Zugriff auf crontab gewährt. fcron kommt standardmäßig mit der Datei fcron.allow die allen Nutzern in der cron-Gruppe Zugriff auf fcrontab gibt.
CODE Berechtigungen in fcron.deny
all

Wenn ein Benutzer (larry wieder für dieses Beispiel) in der Lage sein soll, seine eigenen Cron-Jobs zu planen, dann fügen Sie ihn zu /etc/fcron/fcron.allow wie folgt hinzu:

CODE Berechtigungen in fcron.allow
larry

cronie

Wenn cronie gewählt wurde, dann bearbeiten Sie einfach die Datei /etc/cron.allow.

Wichtig
It is important to note that if only /etc/cron.allow exists, then only the cron group users listed there will have access. Otherwise, if only an empty /etc/cron.deny exists, then all cron group users will be allowed. Do not leave an empty /etc/cron.deny if no /etc/cron.allow file exists!

For example, to allow access to the user larry, add him to /etc/cron.allow as follows:

CODE Berechtigungen in /etc/cron.allow
larry

Planen von Cron-Jobs

The process of editing crontabs is different for each package, but they all support the same basic set of commands: adding and replacing crontabs, editing crontabs, deleting crontabs, and listing cron-jobs in crontabs. The following list shows how to run various commands for each package.

Version crontab bearbeiten Crontab entfernen Neue crontab-Datei Cron-Aufträge auflisten
dcron crontab -e crontab -d [benutzer] crontab file crontab -l
fcron fcrontab -e fcrontab -r [benutzer] fcrontab file fcrontab -l
cronie und bcron crontab -e crontab -r -u [benutzer] crontab file crontab -l
Hinweis
Wenn kein Argument angegeben wird, löscht der Befehl remove die Crontab des aktuellen Benutzers

.

Hinweis
Fcron hat auch einen Symlink von crontab zu fcrontab.

Before any of these commands can be used, first understanding of the crontab itself is needed. Each line in a crontab specifies five time fields in the following order: the minutes (0-59), hours (0-23), days of the month (1-31), months (1-12), and days of the week (0-7, Monday is day 1, Sunday is day 0 and day 7). The days of the week and months can be specified by three-letter abbreviations like mon, tue, jan, feb, etc. Each field can also specify a range of values (e.g. 1-5 or mon-fri), a comma separated list of values (e.g. 1,2,3 or mon,tue,wed) or a range of values with a step (e.g. 1-6/2 as 1,3,5).

That sounds a little confusing, but with a few examples it is easy to see it is not as complicated as it sounds.

CODE Beispiele
# /bin/false jede Minute das ganze Jahr über ausführen
*     *     *     *     *        /bin/false
  
# /bin/false um 1:35 Uhr am Montag, Dienstag, Mittwoch und am 4. eines jeden Monats ausführen.
35    1     4     *     mon-wed  /bin/false
  
# /bin/true um 22:25 Uhr am 2. März ausführen
25    22    2     3     *        /bin/true
  
# /bin/false jeden Montag, Mittwoch und Freitag um 2:00 Uhr ausführen
0     2     *     *     1-5/2    /bin/false
Hinweis
Notice how to specify specific days of the week and days of the month before they are combined. If * is used for only one of them, the other takes precedence, while * for both just means every day.

To test what was just covered go through the steps of actually inputting a few cron-jobs. First, create a file called crons.cron and make it look like the this:

DATEI crons.cronErstellen einer crons.cron-Datei
#Minuten  Stunden  Tage   Monate  Wochentag
10     3      1      1       *       /bin/echo "Ich mag Cron nicht wirklich"
30     16     *      1,2     *       /bin/echo "Ich mag Cron ein wenig"
*      *      *      1-12/2  *       /bin/echo "Ich mag Cron wirklich"

Now add that crontab to the system with the "new command" from the table above.

root #crontab crons.cron
Hinweis
The output from the echo commands will not be seen unless redirection is used.

To verify the scheduled cron-jobs, use the proper list command from the table above.

root #crontab -l

A list resembling crons.cron should be displayed; if not maybe the wrong command was issued to input the crontab.

This crontab should echo "I really like cron" every minute of every hour of every day every other month. Obviously a user would only do that if they really liked cron. The crontab will also echo "I like cron a little" at 16:30 every day in January and February. It will also echo "I don't really like cron" at 3:10 on the January 1st.

If using anacron keep reading this section. Otherwise, proceed to the next section on Editing crontabs.

Anacron users will want to edit /etc/anacrontab. This file has four fields: the number of days between each run, the delay in minutes after which it runs, the name of the job, and the command to run.

Um zum Beispiel alle 5 Tage, 10 Minuten nach dem Start von anacron, echo "Ich mag anacron" laufen zu lassen, geben Sie folgendes ein:

DATEI /etc/anacrontab
5 10 wasting-time /bin/echo "Ich mag anacron"

Anacron exits after all of the jobs in anacrontab have finished. To check to see if these jobs should be performed every day, a cron daemon will be used. The instructions at the end of the next section explain how this should be handled.

Bearbeitung von crontabs

Being realistic, no user would want their system telling them how much they like cron every minute. As a step forward, remove the previous example crontab using the corresponding remove command from the table above. Use the corresponding list command to view the cron-jobs afterward to make sure it worked.

root #crontab -d
root #crontab -l

No cron-jobs should be displayed in the output from crontab -l. If cron jobs are listed, then the remove command failed to remove the crontab; verify the correct remove command for the system's cron package.

Now that we have a clean state, let's put something useful into the root crontab. Most people will want to run updatedb on a weekly basis to make sure that mlocate works properly. To add that to the system's crontab, first edit crons.cron again so that it looks like the following:

CODE Eine echte crontab
22 2 * * 1    /usr/bin/updatedb

That would make cron run updatedb at 2:22 A.M. on Monday morning every week. Now input the crontab with the proper new command from the table above, and check the list again.

root #crontab crons.cron
root #crontab -l

Now let's say emerge --sync should be ran on a daily schedule in order to keep the Portage tree up to date. This could be done by first editing crons.cron and then using crontab crons.cron as was done in the example above, or by using the proper edit command from the table above. This provides a way to edit the user's crontab in situ, without depending on external files like crons.cron.

root #crontab -e

The above command should open the user's crontab with an editor. For example, if emerge --sync is to be run every day at 6:30 A.M., make the crontab look something like this:

CODE Eine echte crontab
22 2 * * 1    /usr/bin/updatedb
30 6 * * *    /usr/bin/emerge --sync
## (Wenn Sie Anacron verwenden, fügen Sie diese Zeile hinzu)
30 7 * * *    /usr/sbin/anacron -s

Again, check the cron-jobs list as done in the previous examples to make sure the jobs are scheduled. If they are all there, then the system is ready to rock and roll.

Verwendung von cronbase

As mentioned earlier, all of the available cron packages depend on sys-process/cronbase. The cronbase package creates /etc/cron.{hourly,daily,weekly,monthly}, and a script called run-crons. Notice the default /etc/crontab file contains something like this:

CODE Standard-System-Crontab
*/15 * * * *     test -x /usr/sbin/run-crons && /usr/sbin/run-crons
0  *  * * *      rm -f /var/spool/cron/lastrun/cron.hourly
0  3  * * *      rm -f /var/spool/cron/lastrun/cron.daily
15 4  * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
30 5  1 * *      rm -f /var/spool/cron/lastrun/cron.monthly

To avoid going into much detail, assume these commands will effectively run hourly, daily, weekly and monthly scripts. This method of scheduling cron-jobs has some important advantages:

  • They will run even if the computer was off when they were scheduled to run;
  • It is easy for package maintainers to place scripts in those well defined places;
  • The administrators know exactly where the cron-jobs and crontab are stored, making it easy to backup and restore these parts of their systems.
Hinweis
Again, it is useful to point out that cronie and bcron automatically read /etc/crontab, while dcron and fcron do not. Please read the System crontab section to learn more about this.

Verwendung von Anacron

As mentioned earlier, anacron is used on systems not meant to be run continuously (like most of the desktop installations). Its default configuration file, /etc/anacrontab, is usually similar to the following:

DATEI /etc/anacrontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Format: Zeitraum Verzögerung Job-Identifikator Befehl
1       5       cron.daily      run-parts /etc/cron.daily
7       10      cron.weekly     run-parts /etc/cron.weekly
30      15      cron.monthly    run-parts /etc/cron.monthly

The main difference between this and other common crontabs is that with anacron there is no fixed date/hour for the job scheduling, but only the period between every run. When anacron is started, it will check the contents of a set of files in /var/spool/anacron and calculate if the corresponding entry in the configuration file has expired since the last run. If it has, then the command is invoked again.

As a final note, it is important to comment out any overlapping entry in any other cron installed in the system, such as in the following vixie-cron crontab example:

DATEI /etc/crontab
# für cronie

<div lang="en" dir="ltr" class="mw-content-ltr">
# Global variables
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
  
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
59  *  * * *    root    rm -f /var/spool/cron/lastrun/cron.hourly
#9  3  * * *    root    rm -f /var/spool/cron/lastrun/cron.daily
#19 4  * * 6    root    rm -f /var/spool/cron/lastrun/cron.weekly
#29 5  1 * *    root    rm -f /var/spool/cron/lastrun/cron.monthly
#*/10  *  * * * root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons
@hourly         root    test ! -e /var/spool/cron/lastrun/cron.hourly && touch /var/spool/cron/lastrun/cron.hourly && run-parts --report /etc/cron.hourly

Without doing this, the daily, weekly, and monthly parts will be executed - at different times - by both the cron daemon and anacron, leading to possible double job executions.

Fehlersuche

When having problems getting cron to work properly, this quick checklist might be helpful.

Remember, each cron package is different and the range of features varies greatly. Be sure to consult the man pages for crontab, fcrontab, or anacrontab, depending on which cron daemon has been activated!

Läuft cron?

Um zu überprüfen, ob cron läuft, sehen Sie nach, ob es in der Prozessliste auftaucht:

user $ps ax | grep cron

Funktioniert Cron?

Versuchen Sie das Folgende:

CODE crontab um zu sehen, ob cron läuft
* * * * * /bin/echo "foobar" >> /tmp/file_you_own.log

Prüfen Sie dann, ob /tmp/file_you_own.log regelmäßig geändert wird.

Funktioniert der Befehl?

Dasselbe wie zuvor, aber vielleicht auch die Standardfehlerausgabe umleiten:

CODE crontab zur Überprüfung der Anwendungsausführung
* * * * * /bin/echo "foobar" >> /tmp/file_you_own 2>&1

Kann cron den Auftrag ausführen?

Überprüfen Sie den Cron-log, normalerweise /var/log/cron.log oder /var/log/messages auf Fehler.

Gibt es irgendwelche dead.letters?

cron sendet normalerweise Mails, wenn es ein Problem gibt; prüfen Sie auf Mails und suchen Sie nach der Erstellung einer ~/dead.letter-Datei.

Warum werden keine Cron-Mails verschickt?

In order to receive mails from cron, a valid MTA setup must be implemented. This is provided by any package from virtual/mta.

If the cron mails are only to be sent locally, and not through a fully configured mail server, the system can use mbox (/var/spool/mail) mails, by enabling the mbox useflag with the respective package which provides the MTA.

External resources


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Eric Brown, Xavier Neys,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.