Documentation for a newer release is available. View Latest

Automatizando Tareas del Sistema

indexterm:[Automated Tasks] Las tareas, también llamadas _trabajos_, se pueden configurar para que se ejecuten automáticamente en un período de tiempo especificado, en una fecha especificada o cuando la media de carga del sistema esté por debajo de 0.8.

Fedora está preconfigurado para ejecutar importantes tareas del sistema para mantenerlo actualizado. Por ejemplo, la base de datos slocate usada por el comando locate se actualiza diariamente. Un administrador del sistema puede usar las tareas automatizadas para llevar a cabo copias de seguridad periódicas, monitorizar el sistema, ejecutar scripts personalizados y demás.

Fedora trae las siguientes utilidades para tareas automatizadas: cron, anacron, at y batch.

Cada utilidad está dirigida para planificar un tipo de trabajo diferente: mientras Cron y Anacron planifican trabajos recurrentes, At y Batch planifican trabajos de una sola ejecución (vea Cron y Anacron y At y Batch respectivamente).

Fedora soporta el uso de systemd.timer para la ejecución de un trabajo a una hora especificada. Vea la página de manual systemd.timer(5) para más información.

Cron y Anacron

Tanto Cron como Anacron pueden planificar la ejecución de tareas recurrentes en un cierto punto del tiempo definido por la hora exacta, día del mes, mes, día de la semana y semana.

Los trabajos Cron se pueden ejecutar con una frecuencia de cada minuto. Sin embargo, la utilidad asume que el sistema está corriendo continuamente y si el sistema no está levantado cuando el trabajo está planificado, el trabajo no se ejecuta.

Por otro lado, Anacron recuerda los trabajos planificados si el sistema no está corriendo en el momento en el que se ha planificado el trabajo. El trabajo se ejecuta entonces una vez se haya levantado el sistema. Sin embargo, Anacron puede ejecutar solo un trabajo una vez al día. También advierta que por defecto, Anacron solo corre cuando su sistema está alimentado con corriente alterna y no correrá si su sistema está alimentado por una batería; este comportamiento está establecido en el script /etc/cron.hourly/0anacron.

Instalando Cron y Anacron

Para instalar Cron y Anacron, usted necesita instalar el paquete cronie con Cron y el paquete cronie-anacron con Anacron, (cronie-anacron es un subpaquete de cronie).

Para determinar si los paquetes ya están instalados en su sistema ejecute el siguiente comando:

rpm -q cronie cronie-anacron

El comando devuelve los nombres completos de los paquetes cronie y cronie-anacron si ya están instalados o notifica que los paquetes no están disponibles.

Para instalar estos paquetes use el comando dnf de la siguiente forma como root:

dnf install package

Por ejemplo, para instalar ambos, Cron y Anacron, teclee lo siguiente en el símbolo del sistema:

~]# dnf install cronie cronie-anacron

Para más información sobre como instalar nuevos paquetes en la instalación de paquetes en Fedora, vea Instalando Paquetes.

Ejecutando el Servicio Crond

Los trabajos cron y anacron son ambos elegidos por el servicio crond. Esta sección suministra información sobre cómo arrancar, parar y reiniciar el servicio crond y muestras como configurarlo para que se inicie automáticamente en el momento del arranque.

Arrancando y Parando el Servicio Cron

Para determinar si el servicio está corriendo, use el siguiente comando:

systemctl status crond.service

To run the crond service in the current session, type the following at a shell prompt as root:

systemctl start crond.service

To configure the service to start automatically at boot time, use the following command as root:

systemctl enable crond.service

Stopping the Cron Service

To stop the crond service in the current session, type the following at a shell prompt as root:

systemctl stop crond.service

To prevent the service from starting automatically at boot time, use the following command as root:

systemctl disable crond.service

Restarting the Cron Service

To restart the crond service, type the following at a shell prompt as root:

systemctl restart crond.service

This command stops the service and starts it again in quick succession.

Configuring Anacron Jobs

The main configuration file to schedule jobs is the /etc/anacrontab file, which can be only accessed by the root user. The file contains the following:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1         5     cron.daily    nice run-parts /etc/cron.daily
7         25    cron.weekly   nice run-parts /etc/cron.weekly
@monthly  45    cron.monthly  nice run-parts /etc/cron.monthly

The first three lines define the variables that configure the environment in which the anacron tasks run:

  • SHELL — shell environment used for running jobs (in the example, the Bash shell)

  • PATH — paths to executable programs

  • MAILTO — username of the user who receives the output of the anacron jobs by email

    If the MAILTO variable is not defined (MAILTO=), the email is not sent.

The next two variables modify the scheduled time for the defined jobs:

  • RANDOM_DELAY — maximum number of minutes that will be added to the delay in minutes variable which is specified for each job

    The minimum delay value is set, by default, to 6 minutes.

    If RANDOM_DELAY is, for example, set to 12, then between 6 and 12 minutes are added to the delay in minutes for each job in that particular anacrontab. RANDOM_DELAY can also be set to a value below 6, including 0. When set to 0, no random delay is added. This proves to be useful when, for example, more computers that share one network connection need to download the same data every day.

  • START_HOURS_RANGE — interval, when scheduled jobs can be run, in hours

    In case the time interval is missed, for example due to a power failure, the scheduled jobs are not executed that day.

The remaining lines in the /etc/anacrontab file represent scheduled jobs and follow this format:

period in days   delay in minutes   job-identifier   command
  • period in days — frequency of job execution in days

    The property value can be defined as an integer or a macro (@daily, @weekly, @monthly), where @daily denotes the same value as integer 1, @weekly the same as 7, and @monthly specifies that the job is run once a month regardless of the length of the month.

  • delay in minutes — number of minutes anacron waits before executing the job

    The property value is defined as an integer. If the value is set to 0, no delay applies.

  • job-identifier — unique name referring to a particular job used in the log files

  • command — command to be executed

    The command can be either a command such as ls /proc >> /tmp/proc or a command which executes a custom script.

Any lines that begin with a hash sign (#) are comments and are not processed.

Examples of Anacron Jobs

The following example shows a simple /etc/anacrontab file:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=30
# the jobs will be started during the following hours only
START_HOURS_RANGE=16-20

#period in days   delay in minutes   job-identifier   command
1         20    dailyjob      nice run-parts /etc/cron.daily
7         25    weeklyjob     /etc/weeklyjob.bash
@monthly  45    monthlyjob    ls /proc >> /tmp/proc

All jobs defined in this anacrontab file are randomly delayed by 6-30 minutes and can be executed between 16:00 and 20:00.

The first defined job is triggered daily between 16:26 and 16:50 (RANDOM_DELAY is between 6 and 30 minutes; the delay in minutes property adds 20 minutes). The command specified for this job executes all present programs in the /etc/cron.daily/ directory using the run-parts script (the run-parts scripts accepts a directory as a command-line argument and sequentially executes every program in the directory). See the run-parts man page for more information on the run-parts script.

The second job executes the weeklyjob.bash script in the /etc/ directory once a week.

The third job runs a command, which writes the contents of /proc to the /tmp/proc file (ls /proc >> /tmp/proc) once a month.

Configuring Cron Jobs

The configuration file for cron jobs is /etc/crontab, which can be only modified by the root user. The file contains the following:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed

The first three lines contain the same variable definitions as an anacrontab file: SHELL, PATH, and MAILTO. For more information about these variables, see Configuring Anacron Jobs.

In addition, the file can define the HOME variable. The HOME variable defines the directory, which will be used as the home directory when executing commands or scripts run by the job.

The remaining lines in the /etc/crontab file represent scheduled jobs and have the following format:

minute   hour   day   month   day of week   username   command

The following define the time when the job is to be run:

  • minute — any integer from 0 to 59

  • hour — any integer from 0 to 23

  • day — any integer from 1 to 31 (must be a valid day if a month is specified)

  • month — any integer from 1 to 12 (or the short name of the month such as jan or feb)

  • day of week — any integer from 0 to 7, where 0 or 7 represents Sunday (or the short name of the week such as sun or mon)

The following define other job properties:

  • username — specifies the user under which the jobs are run.

  • command — the command to be executed.

    The command can be either a command such as ls /proc /tmp/proc or a command which executes a custom script.

For any of the above values, an asterisk (*) can be used to specify all valid values. If you, for example, define the month value as an asterisk, the job will be executed every month within the constraints of the other values.

A hyphen (-) between integers specifies a range of integers. For example, 1-4 means the integers 1, 2, 3, and 4.

A list of values separated by commas (,) specifies a list. For example, 3,4,6,8 indicates exactly these four integers.

The forward slash (/) can be used to specify step values. The value of an integer will be skipped within a range following the range with /integer. For example, the minute value defined as 0-59/2 denotes every other minute in the minute field. Step values can also be used with an asterisk. For instance, if the month value is defined as */3, the task will run every third month.

Any lines that begin with a hash sign (#) are comments and are not processed.

Users other than root can configure cron tasks with the crontab utility. The user-defined crontabs are stored in the /var/spool/cron/ directory and executed as if run by the users that created them.

To create a crontab as a specific user, login as that user and type the command crontab -e to edit the user’s crontab with the editor specified in the VISUAL or EDITOR environment variable. The file uses the same format as /etc/crontab. When the changes to the crontab are saved, the crontab is stored according to the user name and written to the file /var/spool/cron/username. To list the contents of the current user’s crontab file, use the crontab -l command.

The /etc/cron.d/ directory contains files that have the same syntax as the /etc/crontab file. Only root is allowed to create and modify files in this directory.

Do not restart the daemon to apply the changes

The cron daemon checks the /etc/anacrontab file, the /etc/crontab file, the /etc/cron.d/ directory, and the /var/spool/cron/ directory every minute for changes and the detected changes are loaded into memory. It is therefore not necessary to restart the daemon after an anacrontab or a crontab file have been changed.

Controlling Access to Cron

To restrict the access to Cron, you can use the /etc/cron.allow and /etc/cron.deny files. These access control files use the same format with one user name on each line. Mind that no whitespace characters are permitted in either file.

If the cron.allow file exists, only users listed in the file are allowed to use cron, and the cron.deny file is ignored.

If the cron.allow file does not exist, users listed in the cron.deny file are not allowed to use Cron.

The Cron daemon (crond) does not have to be restarted if the access control files are modified. The access control files are checked each time a user tries to add or delete a cron job.

The root user can always use cron, regardless of the user names listed in the access control files.

You can control the access also through Pluggable Authentication Modules (PAM). The settings are stored in the /etc/security/access.conf file. For example, after adding the following line to the file, no other user but the root user can create crontabs:

-:ALL EXCEPT root :cron

The forbidden jobs are logged in an appropriate log file or, when using crontab -e, returned to the standard output. For more information, see the access.conf.5 manual page.

Black and White Listing of Cron Jobs

Black and white listing of jobs is used to define parts of a job that do not need to be executed. This is useful when calling the run-parts script on a Cron directory, such as /etc/cron.daily/: if the user adds programs located in the directory to the job black list, the run-parts script will not execute these programs.

To define a black list, create a jobs.deny file in the directory that run-parts scripts will be executing from. For example, if you need to omit a particular program from /etc/cron.daily/, create the /etc/cron.daily/jobs.deny file. In this file, specify the names of the programs to be omitted from execution (only programs located in the same directory can be enlisted). If a job runs a command which runs the programs from the /etc/cron.daily/ directory, such as run-parts /etc/cron.daily, the programs defined in the jobs.deny file will not be executed.

To define a white list, create a jobs.allow file.

The principles of jobs.deny and jobs.allow are the same as those of cron.deny and cron.allow described in section Controlling Access to Cron.

At and Batch

While Cron is used to schedule recurring tasks, the At utility is used to schedule a one-time task at a specific time and the Batch utility is used to schedule a one-time task to be executed when the system load average drops below 0.8.

Installing At and Batch

To determine if the at package is already installed on your system, issue the following command:

rpm -q at

The command returns the full name of the at package if already installed or notifies you that the package is not available.

To install the packages, use the dnf command in the following form as root:

dnf install package

For example, to install both At and Batch, type the following at a shell prompt:

~]# dnf install at

Para más información sobre como instalar nuevos paquetes en la instalación de paquetes en Fedora, vea Instalando Paquetes.

Running the At Service

The At and Batch jobs are both picked by the atd service. This section provides information on how to start, stop, and restart the atd service, and shows how to configure it to start automatically at boot time.

Starting and Stopping the At Service

Para determinar si el servicio está corriendo, use el siguiente comando:

systemctl status atd.service

To run the atd service in the current session, type the following at a shell prompt as root:

systemctl start atd.service

To configure the service to start automatically at boot time, use the following command as root:

systemctl enable atd.service

It is recommended that you configure your system to start the atd service automatically at boot time.

Stopping the At Service

To stop the atd service, type the following at a shell prompt as root:

systemctl stop atd.service

To prevent the service from starting automatically at boot time, use the following command as root:

systemctl disable atd.service

Restarting the At Service

To restart the atd service, type the following at a shell prompt as root:

systemctl restart atd.service

This command stops the service and starts it again in quick succession.

Configuring an At Job

To schedule a one-time job for a specific time with the At utility, do the following:

  1. On the command line, type the command at TIME, where TIME is the time when the command is to be executed.

    The TIME argument can be defined in any of the following formats:

    • HH:MM specifies the exact hour and minute; For example, 04:00 specifies 4:00 a.m.

    • midnight specifies 12:00 a.m.

    • noon specifies 12:00 p.m.

    • teatime specifies 4:00 p.m.

    • MONTHDAYYEAR format; For example, January 15 2012 specifies the 15th day of January in the year 2012. The year value is optional.

    • MMDDYY, MM/DD/YY, or MM.DD.YY formats; For example, 011512 for the 15th day of January in the year 2012.

    • now + TIME where TIME is defined as an integer and the value type: minutes, hours, days, or weeks. For example, now + 5 days specifies that the command will be executed at the same time five days from now.

      The time must be specified first, followed by the optional date. For more information about the time format, see the /usr/share/doc/at-<version>/timespec text file.

      If the specified time has past, the job is executed at the time the next day.

  2. In the displayed at> prompt, define the job commands:

    1. Type the command the job should execute and press Enter. Optionally, repeat the step to provide multiple commands.

    2. Enter a shell script at the prompt and press Enter after each line in the script.

      The job will use the shell set in the user’s SHELL environment, the user’s login shell, or /bin/sh (whichever is found first).

  3. Once finished, press Ctrl+D on an empty line to exit the prompt.

If the set of commands or the script tries to display information to standard output, the output is emailed to the user.

To view the list of pending jobs, use the atq command. See Viewing Pending Jobs for more information.

You can also restrict the usage of the at command. For more information, see Controlling Access to At and Batch for details.

Configuring a Batch Job

The Batch application executes the defined one-time tasks when the system load average decreases below 0.8.

To define a Batch job, do the following:

  1. On the command line, type the command batch.

  2. In the displayed at> prompt, define the job commands:

    1. Type the command the job should execute and press Enter. Optionally, repeat the step to provide multiple commands.

    2. Enter a shell script at the prompt and press Enter after each line in the script.

      If a script is entered, the job uses the shell set in the user’s SHELL environment, the user’s login shell, or /bin/sh (whichever is found first).

  3. Once finished, press Ctrl+D on an empty line to exit the prompt.

If the set of commands or the script tries to display information to standard output, the output is emailed to the user.

To view the list of pending jobs, use the atq command. See Viewing Pending Jobs for more information.

You can also restrict the usage of the batch command. For more information, see Controlling Access to At and Batch for details.

Viewing Pending Jobs

To view the pending At and Batch jobs, run the atq command. The atq command displays a list of pending jobs, with each job on a separate line. Each line follows the job number, date, hour, job class, and user name format. Users can only view their own jobs. If the root user executes the atq command, all jobs for all users are displayed.

Additional Command Line Options

Additional command line options for at and batch include the following:

Table 1. at and batch Command Line Options
Option Description

-f

Read the commands or shell script from a file instead of specifying them at the prompt.

-m

Send email to the user when the job has been completed.

-v

Display the time that the job is executed.

Controlling Access to At and Batch

You can restrict the access to the at and batch commands using the /etc/at.allow and /etc/at.deny files. These access control files use the same format defining one user name on each line. Mind that no whitespace are permitted in either file.

If the file at.allow exists, only users listed in the file are allowed to use at or batch, and the at.deny file is ignored.

If at.allow does not exist, users listed in at.deny are not allowed to use at or batch.

The at daemon (atd) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to execute the at or batch commands.

The root user can always execute at and batch commands, regardless of the content of the access control files.

Recursos Adicionales

To learn more about configuring automated tasks, see the following installed documentation:

  • cron(8) man page contains an overview of cron.

  • crontab man pages in sections 1 and 5:

    • The manual page in section 1 contains an overview of the crontab file.

    • The man page in section 5 contains the format for the file and some example entries.

  • anacron(8) manual page contains an overview of anacron.

  • anacrontab(5) manual page contains an overview of the anacrontab file.

  • run-parts(4) manual page contains an overview of the run-parts script.

  • /usr/share/doc/at/timespec contains detailed information about the time values that can be used in cron job definitions.

  • at manual page contains descriptions of at and batch and their command line options.