Linux crontab no crontab for root

Linux crontab no crontab for root Техника

Editing the system crontab or setting up a personal crontab for root are probably a bit more portable, not specific to certain Linux distributions and arguably more convenient for a person to maintain, with all jobs in a single file but:

Personally I favour a third option: for each scheduled task drop either

  • a file in /etc/cron.d/ with a cron snippet
  • an executable (script) in the relevant /etc/cron.[hourly |daily |weekly |monthly] directory.

That is easier to script (you can simply create/overwrite/delete such files and you don’t have to muck about in the contents of a single crontab file) and that works well with configuration management tooling and that is what package managers are already doing anyway.

Когда я пишу команду crontab -e в терминале,

я получаю это сообщение об ошибке:

no crontab for root - using an empty one 888

Я не знаю, что означает «888»?

Файл конфигурации crontab / etc / crontab:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
58 * * * * root cd / && run-parts --report /etc/cron.hourly
52 0 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
46 0 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
9 5 28 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#

Пожалуйста, помогите мне.

Linux crontab no crontab for root

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

Дистрибутив Linux Ubuntu 13.10

* * * * * agent /bin/bash /home/agent/rails_projects/project/rake_script.sh 2> /home/agent/errors

Без крона скрипт работает

С crontab -e (или crontab -e -u agent) ошибка:
/bin/sh: 1: agent: not found

Странно, потому что:
agent:x:1000:1000:agent,,,:/home/agent:/bin/bash
в /etc/passwd

Пробовал и прописать в /etc/crontab (без результатов) :

* * * * * agent sh /home/agent/rails_projects/project/rake_script.sh 2> /home/agent/errors

Скрипт должен выполняться от пользователя.

#!/bin/bash
cd /home/agent/rails_projects/project
bundle exec rake db:alarm

  • Вопрос задан

В задании крона нельзя указать пользователя. Там может быть только командная строка. Слово agent интерпретируется как команда, которой нет.

Кроме того, будьте готовы, что при таком запуске скрипта значение $PATH будет отличаться от того, что вы видите в интерактивной сессии, и нужно будет дополнительно сделать . /etc/profile или . ~/.bash_profile.

В crontab -e пользователя указывать не нужно. Просто
* * * * * command

После 2> пробел уберите. Если собираетесь через -e делать, то добавьте пользователя в /etc/cron.allow

Потом сделайте chmod +x /home/agent/rails_projects/project/rake_script.sh и в крон пишите так:

# если в crontab -e, то
* * * * * /home/agent/rails_projects/project/rake_script.sh 2>home/agent/errors

# если в /etc/cron.d/sth или /etc/crontab, то
* * * * * agent /home/agent/rails_projects/project/rake_script.sh 2>home/agent/errors

05 июл. 2023, в 15:18

5000 руб./за проект

05 июл. 2023, в 15:07

1000 руб./за проект

05 июл. 2023, в 14:41

80000 руб./за проект

My Dockerfile appears to build correctly (it tells me so). When I run the container, I get the below error message. I have tried running the commands (CMD) with and without the service’s directory.

crontab.sh basically writes a cron schedule to a text file (cron.jobs) and then imports the text file to crontab.

FROM node:0.10
MAINTAINER Tom

VOLUME /var/log/

RUN mkdir /pulse
ADD . /pulse
WORKDIR /pulse

RUN apt-get update && apt-get install -y cron

ADD *.sh /pulse/
RUN chmod 750 /pulse/crontab.sh && chmod 750 /pulse/

RUN chmod 644 /etc/crontab

CMD cron -f
CMD touch /var/log/cron.log && sh /pulse/crontab.sh && tail -f /var/log/cron.log
CMD cron /pulse/cron.jobs
CMD crontab -l

edited to add crontab.sh

crontab.sh (some crons have been removed):

#!/bin/bash

cat <<- 'EOF' > cron.jobs

0 * * * * node /pulse/scripts/awsPulseTest.js > /tmp/awsPulseTest.log 2>&1

EOF

crontab cron.jobs
no crontab for root
  • Pulse is the name of the service.
  • The version of node is old due to the service, this will be upgraded.
  • The service is essentially for cron jobs in node

asked May 22, 2017 at 7:06

TomFirth's user avatar

1 gold badge2 silver badges7 bronze badges

It’s an issue with the dockerfile (rather than the commands in the file).
Only one CMD is run (the last one) — see https://docs.docker.com/engine/reference/builder/#cmd

There can only be one CMD instruction in a Dockerfile. If you list
more than one CMD then only the last CMD will take effect.

answered May 22, 2017 at 8:45

Paul Haldane's user avatar

Paul Haldane

1 gold badge21 silver badges32 bronze badges

As the other answers have already explained, only one CMD will be run per Dockerfile and the command you want to run is wrong.

But there is a more pressing issue with your setup IMO — Docker containers are not usually designed to work this way. What you should do instead is running the cron services from the host (or your orchestrator) as one-off processes (probably using something like docker run or docker-compose run, or, if for some reason you don’t want to start a separate container for this, I guess you could use docker exec).

This is just my view on how containers should be used though, so obviously you should take it with a grain of salt.

answered May 22, 2017 at 12:53

Artur Ciesielski's user avatar


My guess is that /pulse/crontab.sh (which you don’t show, why?) adds the relevant crontab line to the system wide crontab file /etc/crontab. You later execute the command crontab -l, but this only shows an error because it lists roots personal crontab only (which happens to be empty), not the system-wide one in /etc/crontab. This is all perfectly normal and expected. To show the line your script added, you would replace CMD crontab -l with CMD cat /etc/crontab.

All of this has nothing to to with any dockerfile commands like ADD, RUN or CMD, it’s just basic Linux stuff.

answered May 22, 2017 at 7:27

Sven's user avatar

13 gold badges179 silver badges226 bronze badges

Аватара пользователя

sunny1983

Сообщения: 357
ОС: GNU/Linux 4.x (Fedora, Debian)
Контактная информация:

cron не работает

Есть подозрение, что cron не запускает команды.
В /etc/crontab правила есть, а команда «crontab -u root -l» говорит «no crontab for root».
Так не должно быть?

Аватара пользователя

Bizdelnick

Модератор
Сообщения: 20374
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: cron не работает


Всё правильно. /etc/crontab — это не crontab рута, и синтаксис у него отличается от пользовательских crontab’ов: в нём должно быть дополнительное поле, где указывается пользователь, от имени которого запускается команда.

Аватара пользователя

sunny1983

Сообщения: 357
ОС: GNU/Linux 4.x (Fedora, Debian)
Контактная информация:

Re: cron не работает


Bizdelnick писал(а):

Всё правильно. /etc/crontab — это не crontab рута, и синтаксис у него отличается от пользовательских crontab’ов: в нём должно быть дополнительное поле, где указывается пользователь, от имени которого запускается команда.

Я не про пользовательский, а про рутовый кронтаб спрашивал. Или нет разницы?
Так собственно у меня вопрос, будет ли работать, если «crontab -u root -l» ничего не показывает, а в /etc/crontab следующее:

Код: Выделить всё

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
*/5    *    *    *    *    root    /usr/libexec/atrun
*/15    *    *    *    *    root    /usr/local/bin/python /usr/utm/main.py
*/11    *    *    *    *    operator /usr/libexec/save-entropy
0    *    *    *    *    root    newsyslog
1    3    *    *    *    root    periodic daily
15    4    *    *    6    root    periodic weekly
30    5    1    *    *    root    periodic monthly
1,31    0-5    *    *    *    root    adjkerntz -a

Аватара пользователя

SLEDopit

Модератор
Сообщения: 4814
Статус: фанат консоли (=
ОС: GNU/Debian, RHEL

Re: cron не работает


sunny1983 писал(а):

Я не про пользовательский, а про рутовый кронтаб спрашивал. Или нет разницы?

Ровно это и написано в документации:

Код: Выделить всё

       crontab  is  the  program used to install, deinstall or list the tables
       used to drive the cron(8) daemon in Vixie Cron.   Each  user  can  have
       their    own    crontab,    and    though    these    are    files   in
       /var/spool/cron/crontabs, they are not intended to be edited directly.

// man crontab

Код: Выделить всё

 $ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
<..>

lazhu

Сообщения: 70
ОС: FreeBSD 9-STABLE / clang 3.3
Контактная информация:

Re: cron не работает


SLEDopit писал(а):

sunny1983 писал(а):

Я не про пользовательский, а про рутовый кронтаб спрашивал. Или нет разницы?

Ровно это и написано в документации:

Код: Выделить всё

       crontab  is  the  program used to install, deinstall or list the tables
       used to drive the cron(8) daemon in Vixie Cron.   Each  user  can  have
       their    own    crontab,    and    though    these    are    files   in
       /var/spool/cron/crontabs, they are not intended to be edited directly.

// man crontab

Код: Выделить всё

 $ cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
<..>

Только в *BSD они лежат в /var/cron/tabs. Как и написано в

Код: Выделить всё

man crontab
...
FILES
     /var/cron/allow  List of users allowed to use crontab
     /var/cron/deny   List of users prohibited from using crontab
     /var/cron/tabs   Directory for personal crontab files

Послесловие

Сron — на удивление простая и полезная программа, выполненная в лучших традициях мира Unix. Она не делает ничего лишнего, но свою работу выполняет замечательно на протяжении уже нескольких десятилетий. Ознакомление с кодом той версии, что поставляется с Ubuntu, заняло не больше часа, а удовольствия я получил массу! Надеюсь, я смог поделиться им с вами.

Не знаю, как вам, но мне немного грустно осознавать, что современное программирование с его склонностью к переусложнению и переабстрагированию уже давно не располагает к подобной простоте.

Существует множество современных альтернатив cron: systemd-timers позволяют организовать сложные системы с зависимостями, в fcron можно гибче регулировать потребление ресурсов задачами. Но лично мне всегда хватало простейших crontab.

Словом, любите Unix, используйте простые программы и не забывайте читать маны для вашей платформы!

Хит продаж — Vixie cron 3. 0pl1

Общий предок популярных вариантов cron — Vixie cron 3.0pl1, представленный в рассылке comp.sources.unix в 1992 году. Основные возможности этой версии мы и рассмотрим подробнее.

Vixie cron поставляется в двух программах (cron и crontab). Как обычно, демон отвечает за чтение и запуск задач из системной таблицы задач и таблиц задач отдельных пользователей, а утилита crontab — за редактирование пользовательских таблиц.

Таблица задач и файлы конфигурации

Таблица задач суперпользователя расположена в /etc/crontab. Синтаксис системной таблицы соответствует синтаксису Vixie cron с поправкой на то, что в ней шестой колонкой указывается имя пользователя, от лица которого запускается задача:

# Запускается ежеминутно от пользователя vlad
* * * * * vlad /path/to/exec

Управление списками пользователей, имеющих доступ к crontab, происходит в файлах /var/cron/allow и /var/cron/deny, куда достаточно внести имя пользователя отдельной строкой.

Расширенный синтаксис

По сравнению с POSIX crontab решение Пола Викси содержит несколько очень полезных модификаций в синтаксисе таблиц задач утилиты.

Стал доступен новый синтаксис таблиц: например, можно указывать дни недели или месяцы поимённо (Mon, Tue и так далее):

# Запускается ежеминутно по понедельникам и вторникам в январе
* * * Jan Mon,Tue /path/to/exec

Можно указывать шаг, через который запускаются задачи:

# Запускается с шагом в две минуты
*/2 * * * Mon,Tue /path/to/exec

Шаги и интервалы можно смешивать:

# Запускается с шагом в две минуты в первых десять минут каждого часа
0-10/2 * * * * /path/to/exec

Поддерживаются интуитивные альтернативы обычному синтаксису (reboot, yearly, annually, monthly, weekly, daily, midnight, hourly):

# Запускается после перезагрузки системы
@reboot /exec/on/reboot
# Запускается раз в день
@daily /exec/daily
# Запускается раз в час
@hourly /exec/daily

Среда выполнения задач

Vixie cron позволяет менять окружение запускаемых приложений.

Некоторые переменные окружения (прежде всего SHELL и HOME) используются самим cron для запуска задачи. Вот как может выглядеть использование bash вместо стандартного sh для запуска пользовательских задач:

SHELL=/bin/bash
HOME=/tmp/
# exec будет запущен bash-ем в /tmp/
* * * * * /path/to/exec

В конечном итоге все определённые в таблице переменные окружения (используемые cron или необходимые процессу) будут переданы запущенной задаче.

Для редактирования файлов утилитой crontab используется редактор, указанный в переменной окружения VISUAL или EDITOR. Если в среде, где был запущен crontab, эти переменные не определены, то используется «/usr/ucb/vi» (ucb — это, вероятно, University of California, Berkeley).

Cronie в RedHat, Fedora и CentOS

cronie — форк Vixie cron версии 4.1. Как и в Debian, синтаксис не менялся, но добавлена поддержка PAM и SELinux, работы в кластере, слежения за файлами при помощи inotify и других возможностей.

Конфигурация по умолчанию находится в обычных местах: системная таблица — в /etc/crontab, пакеты помещают свои таблицы в /etc/cron.d, пользовательские таблицы попадают в /var/spool/cron/crontabs.

Демон запускается под управлением systemd, конфигурация сервиса — /lib/systemd/system/crond.service.

В Red Hat-подобных дистрибутивах при запуске по умолчанию используется /bin/sh, в роли которого выступает стандартный bash. Надо заметить, что при запуске задач cron через /bin/sh командная оболочка bash запускается в POSIX-совместимом режиме и не читает никакой дополнительной конфигурации, работая в неинтерактивном режиме.

POSIX crontab

Если оригинальный cron всегда работал для суперпользователя, то современные планировщики чаще имеют дело с задачами обычных пользователей, что более безопасно и удобно.

Сron-ы поставляются комплектом из двух программ: постоянно работающего демона cron и доступной пользователям утилиты crontab. Последняя позволяет редактировать таблицы задач, специфичные для каждого пользователя в системе, демон же запускает задачи из пользовательских и системной таблиц.

В стандарте POSIX никак не описывается поведение демона и формализована только пользовательская программа crontab. Существование механизмов запуска пользовательских задач, конечно, подразумевается, но не описано подробно.

Вызовом утилиты crontab можно сделать четыре вещи: отредактировать пользовательскую таблицу задач в редакторе, загрузить таблицу из файла, показать текущую таблицу задач и очистить таблицу задач. Примеры работы утилиты crontab:

crontab -e # редактировать таблицу задач
crontab -l # показать таблицу задач
crontab -r # удалить таблицу задач
crontab path/to/file.crontab # загрузить таблицу задач из файла

При вызове crontab -e будет использоваться редактор, указанный в стандартной переменной окружения EDITOR.

Сами задачи описаны в следующем формате:

# строки-комментарии игнорируются
#
# задача, выполняемая ежеминутно
* * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте каждого часа
10 * * * * /path/to/exec -a -b -c
# задача, выполняемая на 10-й минуте второго часа каждого дня и использующая перенаправление стандартного потока вывода
10 2 * * * /path/to/exec -a -b -c > /tmp/cron-job-output.log

В первых пяти полях значения можно перечислять через запятую:

# задача, выполняемая в первую и десятую минуты каждого часа
1,10 * * * * /path/to/exec -a -b -c

Или через дефис:

# задача, выполняемая в каждую из первых десяти минут каждого часа
0-9 * * * * /path/to/exec -a -b -c

Доступ пользователей к планированию задач регулируется в POSIX файлам cron.allow и cron.deny в которых перечисляются, соответственно, пользователи с доступом к crontab и пользователи без доступа к программе. Расположение этих файлов стандарт никак не регламентирует.

Запускаемым программам, согласно стандарту, должны передаваться по меньшей мере четыре переменные окружения:

  1. HOME — домашняя директория пользователя.
  2. LOGNAME — логин пользователя.
  3. PATH — путь, по которому можно найти стандартные утилиты системы.
  4. SHELL — путь к использованному командному интерпретатору.

Примечательно, что POSIX ничего не говорит о том, откуда берутся значения для этих переменных.

Cronie в SLES и openSUSE

Немецкий дистрибутив SLES и его дериватив openSUSE используют всё тот же cronie. Демон здесь тоже запускается под systemd, конфигурация сервиса лежит в /usr/lib/systemd/system/cron.service. Конфигурация: /etc/crontab, /etc/cron.d, /var/spool/cron/tabs. В качестве /bin/sh выступает тот же самый bash, запущенный в POSIX-совместимом неинтерактивном режиме.

Cron в Debian и Ubuntu

Разработчики Debian и производных дистрибутивов выпустили сильно модифицированную версию версию Vixie cron 3.0pl1. Отличий в синтаксисе файлов-таблиц нет, для пользователей это тот же самый Vixie cron. Крупнейшие новые возможности: поддержка syslog, SELinux и PAM.

Из менее заметных, но осязаемых изменений — расположение конфигурационных файлов и таблиц задач.

Пользовательские таблицы в Debian располагаются в директории /var/spool/cron/crontabs, системная таблица всё там же — в /etc/crontab. Специфичные для пакетов Debian таблицы задач помещаются в /etc/cron.d, откуда демон cron их автоматически считывает. Управление доступом пользователей регулируется файлами /etc/cron.allow и /etc/cron.deny.

В качестве командной оболочки по умолчанию по-прежнему используется /bin/sh, в роли которого в Debian выступает небольшой POSIX-совместимый шелл dash, запущенный без чтения какой-либо конфигурации (в неинтерактивном режиме).

Сам cron в последних версиях Debian запускается через systemd, а конфигурацию запуска можно посмотреть в /lib/systemd/system/cron.service. Ничего особенного в конфигурации сервиса нет, любое более тонкое управление задачами возможно осуществить через переменные окружения, объявленные прямо в crontab каждого из пользователей.

Ответа

Это количество символов в файле по умолчанию. Ubuntu создает «пустой» файл crontab с большим количеством комментариев, показывающих, как его использовать.

crontab -e 
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
"/tmp/crontab.vILdXR/crontab" 22L, 888C

Ваш crontab редактор был переключен на ed. Чтобы выйти ed, нажмите Q , а затем Enter . Это выйдет из редактора ed.

Если вы хотите изменить свой crontab редактор обратно на nano, используйте:

sudo select-editor

Это также может быть полезно:

EDITOR=nano crontab -e

ответ дан
12 February 2014 в 23:09

Другие вопросы по тегам:

Похожие вопросы:

Происхождение видов

Периодическое выполнение пользовательских или системных программ — очевидная необходимость во всех операционных системах. Поэтому потребность в сервисах, позволяющих централизованно планировать и выполнять задачи, программисты осознали очень давно.

Unix-подобные операционные системы ведут свою родословную от Version 7 Unix, разработанной в 70-х годах прошлого века в Bell Labs в том числе и знаменитым Кеном Томпсоном (англ. Ken Thompson). Вместе c Version 7 Unix поставлялся и cron, сервис для регулярного выполнения задач суперпользователя.

Типичный современный cron — несложная программа, но алгоритм работы оригинального варианта был ещё проще: сервис просыпался раз в минуту, читал табличку с задачами из единственного файл (/etc/lib/crontab) и выполнял для суперпользователя те задачи, которые следовало выполнить в текущую минуту.

Впоследствии усовершенствованные варианты простого и полезного сервиса поставлялись со всеми Unix-подобными операционными системами.

Обобщённые описания формата crontab и базовых принципов работы утилиты в 1992 году были включены в главный стандарт Unix-подобных операционных систем — POSIX — и таким образом cron из стандарта де-факто стал стандартом де-юре.

В 1987 году Пол Викси (англ. Paul Vixie), опросив пользователей Unix на предмет пожеланий к cron, выпустил ещё одну версию демона, исправляющую некоторые проблемы традиционных cron и расширяющую синтаксис файлов-таблиц.

К третьей версии Vixie cron стал отвечать требованиям POSIX, к тому же у программы была либеральная лицензия, вернее не было вообще никакой лицензии, если не считать пожеланий в README: гарантий автор не даёт, имя автора удалять нельзя, а продавать программу можно только вместе с исходным кодом. Эти требования оказались совместимы с принципами набиравшего в те годы популярность свободного ПО, поэтому некоторые ключевые из появившихся в начале 90-х дистрибутивов Linux взяли Vixie cron в качестве системного и развивают его до сих пор.

В частности, Red Hat и SUSE развивают форк Vixie cron — cronie, а Debian и Ubuntu используют оригинальное издание Vixie cron со множеством патчей.

Давайте для начала познакомимся с описанной в POSIX пользовательской утилитой crontab, после чего разберём расширения синтаксиса, представленные в Vixie cron, и использование вариаций Vixie cron в популярных дистрибутивах Linux. И, наконец, вишенка на торте — разбор устройства демона cron.

Устройство Vixie cron

Современные потомки cron по сравнению с Vixie cron не изменились радикально, но всё же обзавелись новыми возможностями, не требующимися для понимания принципов работы программы. Многие из этих расширений оформлены неаккуратно и путают код. Оригинальный же исходный код cron в исполнении Пола Викси читать одно удовольствие.

Поэтому разбор устройства cron я решил провести на примере общей для обеих ветвей развития cron программы — Vixie cron 3.0pl1. Примеры я упрощу, убрав усложняющие чтение ifdef-ы и опустив второстепенные детали.

Работу демона можно разделить на несколько этапов:

  1. Инициализация программы.
  2. Сбор и обновление списка задач для запуска.
  3. Работа главного цикла cron.
  4. Запуск задачи.

Разберём их по порядку.

Инициализация

При запуске после проверки аргументов процесса cron устанавливает обработчики сигналов SIGCHLD и SIGHUP. Первый вносит в лог запись о завершении работы дочернего процесса, второй — закрывает файловый дескриптор файла-лога:

signal(SIGCHLD, sigchld_handler);
signal(SIGHUP, sighup_handler);

Демон cron в системе всегда работает один, только в роли суперпользователя и из главной директории cron. Следующие вызовы создают файл-лок с PID-ом процесса-демона, убеждаются, что пользователь правильный и меняют текущую директорию на главную:

acquire_daemonlock(0);
set_cron_uid();
set_cron_cwd();

Выставляется путь по умолчанию, который будет использоваться при запуске процессов:

setenv("PATH", _PATH_DEFPATH, 1);

Дальше процесс «демонизируется»: создаёт дочернюю копию процесса вызовом fork и новую сессию в дочернем процессе (вызов setsid). В родительском процессе больше надобности нет — и он завершает работу:

switch (fork()) {
case -1:
    /* критическая ошибка и завершение работы */
    exit(0);
break;
case 0:
    /* дочерний процесс */
    (void) setsid();
break;
default:
    /* родительский процесс завершает работу */
    _exit(0);
}

Завершение родительского процесса высвобождает лок на файле-локе. Кроме того, требуется обновить PID в файле на дочерний. После этого заполняется база задач:

/* повторный захват лока */
acquire_daemonlock(0);

/* Заполнение БД  */
database.head = NULL;
database.tail = NULL;
database.mtime = (time_t) 0;
load_database(&database);

Дальше cron переходит к главному циклу работы. Но перед этим стоит взглянуть на загрузку списка задач.

Сбор и обновление списка задач

За загрузку списка задач отвечает функция load_database. Она проверяет главный системный crontab и директорию с пользовательскими файлами. Если файлы и директория не менялись, то список задач не перечитывается. В противном случае начинает формироваться новый список задач.

Загрузка системного файла со специальными именами файла и таблицы:

/* если файл системной таблицы изменился, перечитываем */
if (syscron_stat.st_mtime) {
    process_crontab("root", "*system*",
    SYSCRONTAB, &syscron_stat,
    &new_db, old_db);
}

Загрузка пользовательских таблиц в цикле:

while (NULL != (dp = readdir(dir))) {
    char    fname[MAXNAMLEN+1],
            tabname[MAXNAMLEN+1];
    /* читать файлы с точкой не надо*/
    if (dp->d_name[0] == '.')
            continue;
    (void) strcpy(fname, dp->d_name);
    sprintf(tabname, CRON_TAB(fname));
    process_crontab(fname, fname, tabname,
                    &statbuf, &new_db, old_db);
}

После чего старая база данных подменяется новой.

while ((status = load_env(envstr, file)) >= OK) {
    switch (status) {
    case ERR:
        free_user(u);
        u = NULL;
        goto done;
    case FALSE:
        e = load_entry(file, NULL, pw, envp);
        if (e) {
            e->next = u->crontab;
            u->crontab = e;
        }
        break;
    case TRUE:
        envp = env_set(envp, envstr);
        break;
    }
}

Здесь либо выставляется переменная окружения (строки вида VAR=value) функциями load_env / env_set, либо читается описание задачи (* * * * * /path/to/exec) функцией load_entry.

Сущность entry, которую возвращает load_entry, — это и есть наша задача, помещаемая в общий список задач. В самой функции проводится многословный разбор формата времени, нас же больше интересует формирование переменных окружения и параметров запуска задачи:

/* пользователь и группа для запуска задачи берутся из passwd*/
e->uid = pw->pw_uid;
e->gid = pw->pw_gid;

/* шелл по умолчанию (/bin/sh), если пользователь не указал другое */
e->envp = env_copy(envp);
if (!env_get("SHELL", e->envp)) {
    sprintf(envstr, "SHELL=%s", _PATH_BSHELL);
    e->envp = env_set(e->envp, envstr);
}
/* домашняя директория */
if (!env_get("HOME", e->envp)) {
    sprintf(envstr, "HOME=%s", pw->pw_dir);
    e->envp = env_set(e->envp, envstr);
}
/* путь для поиска программ */
if (!env_get("PATH", e->envp)) {
    sprintf(envstr, "PATH=%s", _PATH_DEFPATH);
    e->envp = env_set(e->envp, envstr);
}
/* имя пользовтеля всегда из passwd */
sprintf(envstr, "%s=%s", "LOGNAME", pw->pw_name);
e->envp = env_set(e->envp, envstr);

С актуальным списком задач и работает главный цикл.

Главный цикл

Оригинальный cron из Version 7 Unix работал совсем просто: в цикле перечитывал конфигурацию, запускал суперпользователем задачи текущей минуты и спал до начала следующей минуты. Этот простой подход на старых машинах требовал слишком много ресурсов.

В SysV была предложена альтернативная версия, в которой демон засыпал либо до ближайшей минуты, для которой определена задача, либо на 30 минут. Ресурсов на перечитывание конфигурации и проверку задач в таком режиме потреблялось меньше, но быстро обновлять список задач стало неудобно.

Vixie cron вернулся к проверке списков задач раз в минуту, благо к концу 80-х ресурсов на стандартных Unix-машинах стало значительно больше:

/* первичная загрузка задач */
load_database(&database);
/* запустить задачи, поставленные к выполнению после перезагрузки системы */
run_reboot_jobs(&database);
/* сделать TargetTime началом ближайшей минуты */
cron_sync();
while (TRUE) {
    /* выполнить задачи, после чего спать до TargetTime с поправкой на время, потраченное на задачи */
    cron_sleep();

    /* перечитать конфигурацию */
    load_database(&database);

    /* собрать задачи для данной минуты */
    cron_tick(&database);

    /* перевести TargetTime на начало следующей минуты */
    TargetTime += 60;
}

Непосредственно выполнением задач занимается функция cron_sleep, вызывающая функции job_runqueue (перебор и запуск задач) и do_command (запуск каждой отдельной задачи). Последнюю функцию стоит разобрать подробнее.

Запуск задачи

Функция do_command исполнена в хорошем Unix-стиле, то есть для асинхронного выполнения задачи она делает fork. Родительский процесс продолжает запуск задач, дочерний — занимается подготовкой процесса задачи:

switch (fork()) {
case -1:
    /*не смогли выполнить fork */
    break;
case 0:
    /* дочерний процесс: на всякий случай еще раз пробуем захватить главный лок */
    acquire_daemonlock(1);
    /* переходим к формированию процесса задачи */
    child_process(e, u);
    /* по завершению дочерний процесс заканчивает работу */
    _exit(OK_EXIT);
    break;
default:
    /* родительский процесс продолжает работу */
    break;
}

В child_process довольно много логики: она принимает стандартные потоки вывода и ошибок на себя, чтобы потом переслать на почту (если в таблице задач указана переменная окружения MAILTO), и, наконец, ждёт завершения работы основного процесса задачи.

Процесс задачи формируется еще одним fork:

switch (vfork()) {
case -1:
    /* при ошибки сразу завершается работа */
    exit(ERROR_EXIT);
case 0:
    /* процесс-внук формирует новую сессию, терминал и т.д.
     */
    (void) setsid();

    /*
     * дальше многословная настройка вывода процесса, опустим для краткости
     */

    /* смена директории, пользователя и группы пользователя,
     * то есть процесс больше не суперпользовательский
     */
    setgid(e->gid);
    setuid(e->uid);
    chdir(env_get("HOME", e->envp));

    /* запуск самой команды
     */
    {
        /* переменная окружения SHELL указывает на интерпретатор для запуска */
        char    *shell = env_get("SHELL", e->envp);

        /* процесс запускается без передачи окружения родительского процесса,
         * то есть именно так, как описано в таблице задач пользователя  */
        execle(shell, shell, "-c", e->cmd, (char *)0, e->envp);

        /* ошибка — и процесс на запустился? завершение работы */
        perror("execl");
        _exit(ERROR_EXIT);
    }
    break;
default:
    /* сам процесс продолжает работу: ждет завершения работы и вывода */
    break;
}

Вот, в общем-то, и весь cron. Какие-то интересные детали, например учёт удалённых пользователей, я опустил, но главное изложил.

Дополнительно:  Не работает клавиатура на ноутбуке Леново: почему перестала печатать
Оцените статью
Master Hi-technology
Добавить комментарий