고전은 행복한 시간이 지켜지지 않는다고 썼습니다. 그 시절에는 프로그래머도 유닉스도 없었지만 오늘날 프로그래머들은 확실히 알고 있습니다. cron이 그들 대신 시간을 추적한다는 것입니다.

명령줄 유틸리티는 나에게 약점이자 귀찮은 일입니다. sed, awk, wc, cut 및 기타 오래된 프로그램은 매일 우리 서버의 스크립트에 의해 실행됩니다. 그 중 다수는 원래 70년대의 스케줄러인 cron을 위한 작업으로 설계되었습니다.

오랫동안 자세한 내용을 다루지 않고 피상적으로 cron을 사용해왔는데, 어느 날 스크립트를 실행하다가 오류가 발생하자 꼼꼼히 살펴보기로 했습니다. 이 글을 쓰는 동안 나는 인기 있는 Linux 배포판의 주요 크론 옵션인 POSIX crontab과 그 중 일부의 구조에 익숙해졌습니다.

Linux를 사용하고 cron 작업을 실행하고 있습니까? Unix의 시스템 애플리케이션 아키텍처에 관심이 있습니까? 그럼 출발하겠습니다!

내용

• 종의 기원
• POSIX 크론탭
• 베스트셀러 - Vixie cron 3.0pl1
• 데비안과 우분투의 크론
• Red Hat, Fedora 및 CentOS의 크로니
• SLES 및 openSUSE의 크로니
• Vixie 크론 장치
• 사후

종의 기원

사용자 또는 시스템 프로그램의 주기적인 실행은 모든 운영 체제에서 명백히 필요합니다. 따라서 프로그래머들은 중앙에서 작업을 계획하고 실행할 수 있는 서비스의 필요성을 오래 전부터 인식했습니다.

Unix 계열 운영 체제의 기원은 유명한 Ken Thompson을 포함하여 지난 세기 7년대 Bell Labs에서 개발된 버전 70 Unix로 거슬러 올라갑니다. 버전 7 Unix에는 정기적으로 슈퍼유저 작업을 실행하는 서비스인 cron도 포함되어 있습니다.

일반적인 최신 cron은 간단한 프로그램이지만 원래 버전의 운영 알고리즘은 훨씬 더 간단했습니다. 서비스는 XNUMX분에 한 번씩 깨어나고 단일 파일(/etc/lib/crontab)에서 작업이 포함된 테이블을 읽고 다음 작업을 수행했습니다. 현재 순간에 수행되어야 하는 작업을 수퍼유저로 지정합니다.

그 후 모든 Unix 계열 운영 체제에는 간단하고 유용한 서비스의 향상된 버전이 제공되었습니다.

crontab 형식에 대한 일반화된 설명과 유틸리티 작동의 기본 원리는 1992년 유닉스 계열 운영 체제의 주요 표준인 POSIX에 포함되어 사실상 표준의 cron이 법적 표준이 되었습니다.

1987년에 Unix 사용자들에게 cron에 대한 희망사항을 조사한 Paul Vixie는 기존 cron의 일부 문제를 수정하고 테이블 파일의 구문을 확장한 또 다른 버전의 데몬을 출시했습니다.

Vixie cron의 세 번째 버전에서는 POSIX 요구 사항을 충족하기 시작했습니다. 또한 프로그램에는 자유 라이센스가 있거나 README의 희망 사항을 제외하고는 라이센스가 전혀 없었습니다. 작성자는 보증을 제공하지 않습니다. 작성자 이름 삭제할 수 없으며, 프로그램은 소스코드와 함께 판매만 가능합니다. 이러한 요구 사항은 그 당시 인기를 얻었던 자유 소프트웨어의 원칙과 호환되는 것으로 판명되었으므로 90년대 초반에 등장한 일부 주요 Linux 배포판은 Vixie cron을 시스템 시스템으로 채택했으며 오늘날에도 여전히 개발 중입니다.

특히 Red Hat과 SUSE는 Vixie cron의 포크인 cronie를 개발하고 있으며, Debian과 Ubuntu는 많은 패치가 포함된 Vixie cron의 원본 버전을 사용합니다.

먼저 POSIX에 설명된 사용자 유틸리티 crontab에 대해 알아본 후 Vixie cron에서 제공되는 구문 확장과 인기 있는 Linux 배포판에서 Vixie cron의 변형 사용을 살펴보겠습니다. 그리고 마지막으로 가장 중요한 것은 cron 데몬 장치에 대한 분석입니다.

POSIX 크론탭

원래 크론이 항상 수퍼유저를 위해 작동했다면 최신 스케줄러는 일반 사용자의 작업을 처리하는 경우가 많아 더 안전하고 편리합니다.

크론은 지속적으로 실행되는 크론 데몬과 사용자가 사용할 수 있는 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개 필드: 분 [60..0], 시간 [23..1], 날짜 [31..1], 월 [12..0], 요일 [6. .0], 여기서 XNUMX은 일요일입니다. 마지막 여섯 번째 필드는 표준 명령 해석기에 의해 실행되는 줄입니다.

처음 XNUMX개 필드에는 값을 쉼표로 구분하여 나열할 수 있습니다.

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

또는 하이픈을 사용하여:

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

작업 일정에 대한 사용자 액세스는 POSIX에서 cron.allow 및 cron.deny 파일에 의해 규제됩니다. 이 파일에는 각각 crontab에 액세스할 수 있는 사용자와 프로그램에 액세스할 수 없는 사용자가 나열되어 있습니다. 표준은 어떤 방식으로든 이러한 파일의 위치를 ​​규제하지 않습니다.

표준에 따르면 실행된 프로그램에는 최소 XNUMX개의 환경 변수가 전달되어야 합니다.

1. HOME - 사용자의 홈 디렉토리입니다.
2. LOGNAME — 사용자 로그인.
3. PATH는 표준 시스템 유틸리티를 찾을 수 있는 경로입니다.
4. SHELL — 사용된 명령 해석기의 경로입니다.

특히 POSIX는 이러한 변수의 값이 어디서 왔는지에 대해 아무 말도 하지 않습니다.

베스트셀러 - Vixie cron 3.0pl1

인기 있는 cron 변종의 공통 조상은 3.0년 comp.sources.unix 메일링 리스트에 소개된 Vixie cron 1pl1992입니다. 이 버전의 주요 기능을 더 자세히 살펴보겠습니다.

Vixie cron은 두 가지 프로그램(cron과 crontab)으로 제공됩니다. 평소와 마찬가지로 데몬은 시스템 작업 테이블과 개별 사용자 작업 테이블에서 작업을 읽고 실행하는 역할을 하며, crontab 유틸리티는 사용자 테이블 편집을 담당합니다.

작업 테이블 및 구성 파일

수퍼유저 작업 테이블은 /etc/crontab에 있습니다. 시스템 테이블의 구문은 Vixie cron의 구문과 일치합니다. 단, 여섯 번째 열은 작업이 시작된 사용자의 이름을 나타냅니다.

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

일반 사용자 작업 테이블은 /var/cron/tabs/username에 있으며 동일한 구문을 사용합니다. 사용자로 crontab 유틸리티를 실행할 때 편집되는 파일은 다음과 같습니다.

crontab에 액세스할 수 있는 사용자 목록은 /var/cron/allow 및 /var/cron/deny 파일에서 관리되며, 여기서 별도의 줄에 사용자 이름을 입력하면 됩니다.

확장 구문

POSIX crontab과 비교하여 Paul Vixey의 솔루션에는 유틸리티 작업 테이블 구문에 대한 몇 가지 매우 유용한 수정 사항이 포함되어 있습니다.

새로운 테이블 구문을 사용할 수 있게 되었습니다. 예를 들어 이름으로 요일이나 월을 지정할 수 있습니다(월, 화 등).

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

작업이 시작되는 단계를 지정할 수 있습니다.

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

단계와 간격을 혼합할 수 있습니다.

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

일반적인 구문에 대한 직관적인 대안이 지원됩니다(재부팅, 매년, 매년, 매월, 매주, 매일, 자정, 매시간).

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

태스크 실행 환경

Vixie cron을 사용하면 실행 중인 애플리케이션의 환경을 변경할 수 있습니다.

환경 변수 USER, LOGNAME 및 HOME은 단순히 데몬에 의해 제공되는 것이 아니라 파일에서 가져옵니다. passwd. PATH 변수는 "/usr/bin:/bin"으로 설정되고 SHELL 변수는 "/bin/sh"로 설정됩니다. LOGNAME을 제외한 모든 변수의 값은 사용자 테이블에서 변경 가능합니다.

일부 환경 변수(주로 SHELL 및 HOME)는 cron 자체에서 작업을 실행하는 데 사용됩니다. 표준 sh 대신 bash를 사용하여 사용자 지정 작업을 실행하는 모습은 다음과 같습니다.

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

궁극적으로 테이블에 정의된 모든 환경 변수(cron에서 사용하거나 프로세스에서 필요)가 실행 중인 작업에 전달됩니다.

파일을 편집하기 위해 crontab은 VISUAL 또는 EDITOR 환경 변수에 지정된 편집기를 사용합니다. crontab이 실행된 환경에 이러한 변수가 정의되어 있지 않으면 "/usr/ucb/vi"가 사용됩니다(ucb는 아마도 University of California, Berkeley일 것입니다).

데비안과 우분투의 크론

데비안 및 파생 배포판 개발자가 출시했습니다. 고도로 수정된 버전 Vixie 크론 버전 3.0pl1. 테이블 파일의 구문에는 차이가 없으며 사용자의 경우 동일한 Vixie cron입니다. 가장 큰 새로운 기능: 지원 syslog, SELinux를 и WFP.

눈에 띄지는 않지만 실질적인 변경 사항에는 구성 파일 및 작업 테이블의 위치가 포함됩니다.

Debian의 사용자 테이블은 /var/spool/cron/crontabs 디렉토리에 있으며, 시스템 테이블은 여전히 ​​/etc/crontab에 있습니다. 데비안 패키지별 작업 테이블은 /etc/cron.d에 있으며 cron 데몬이 자동으로 테이블을 읽습니다. 사용자 액세스 제어는 /etc/cron.allow 및 /etc/cron.deny 파일에 의해 제어됩니다.

기본 셸은 여전히 ​​/bin/sh이며 Debian에서는 작은 POSIX 호환 셸입니다. 대시, 구성을 읽지 않고 실행됩니다(비대화형 모드에서).

최신 버전의 Debian에서 Cron 자체는 systemd를 통해 시작되며, 시작 구성은 /lib/systemd/system/cron.service에서 볼 수 있습니다. 서비스 구성에는 특별한 것이 없으며, 각 사용자의 crontab에 직접 선언된 환경 변수를 통해 보다 세밀한 작업 관리가 가능합니다.

RedHat, Fedora 및 CentOS의 크로니

크로니 — Vixie cron 버전 4.1의 포크. Debian에서와 마찬가지로 구문은 변경되지 않았지만 클러스터에서 작동하는 PAM 및 SELinux에 대한 지원, inotify 및 기타 기능을 사용한 파일 추적이 추가되었습니다.

기본 구성은 일반적인 위치에 있습니다. 시스템 테이블은 /etc/crontab에 있고, 패키지는 해당 테이블을 /etc/cron.d에, 사용자 테이블은 /var/spool/cron/crontabs에 있습니다.

데몬은 시스템 제어 하에 실행되며 서비스 구성은 /lib/systemd/system/crond.service입니다.

Red Hat과 유사한 배포판에서는 시작 시 기본적으로 표준 bash인 /bin/sh가 사용됩니다. /bin/sh를 통해 cron 작업을 실행할 때 bash 쉘은 POSIX 호환 모드에서 시작되고 비대화형 모드에서 실행되는 추가 구성을 읽지 않는다는 점에 유의해야 합니다.

SLES 및 openSUSE의 크로니

독일 배포판 SLES와 그 파생 openSUSE는 동일한 크로니를 사용합니다. 여기의 데몬은 systemd에서도 시작되며 서비스 구성은 /usr/lib/systemd/system/cron.service에 있습니다. 구성: /etc/crontab, /etc/cron.d, /var/spool/cron/tabs. /bin/sh는 POSIX 호환 비대화형 모드에서 실행되는 동일한 bash입니다.

Vixie 크론 장치

현대 cron의 후손은 Vixie cron에 비해 근본적으로 변경되지 않았지만 프로그램의 원리를 이해하는 데 필요하지 않은 새로운 기능을 여전히 획득했습니다. 이러한 확장 중 다수는 제대로 설계되지 않았으며 코드를 혼란스럽게 합니다. Paul Vixey가 작성한 원본 cron 소스 코드는 읽기에 좋습니다.

따라서 저는 두 개발 분기 모두에 공통적인 cron 프로그램인 Vixie cron 3.0pl1의 예를 사용하여 cron 장치를 분석하기로 결정했습니다. 읽기를 복잡하게 만드는 ifdef를 제거하고 사소한 세부 사항을 생략하여 예제를 단순화하겠습니다.

악마의 활동은 여러 단계로 나눌 수 있습니다.

1. 프로그램 초기화.
2. 실행할 작업 목록을 수집하고 업데이트합니다.
3. 기본 크론 루프가 실행 중입니다.
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);

그런 다음 프로세스는 "데몬화"됩니다. 즉, 하위 프로세스(setid 호출)에서 분기 및 새 세션을 호출하여 프로세스의 하위 복사본을 생성합니다. 상위 프로세스는 더 이상 필요하지 않으며 종료됩니다.

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);
}

그런 다음 기존 데이터베이스가 새 데이터베이스로 교체됩니다.

위의 예에서 process_crontab 함수 호출은 테이블 파일 이름과 일치하는 사용자가 존재하는지(수퍼유저가 아닌 경우) 확인한 다음 load_user를 호출합니다. 후자는 이미 파일 자체를 한 줄씩 읽습니다.

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;
    }
}

여기서는 load_env / env_set 함수를 사용하여 환경 변수를 설정하거나(VAR=value 형식의 줄) load_entry 함수를 사용하여 작업 설명을 읽습니다(* * * * * /path/to/exec).

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);

메인 루프는 현재 작업 목록과 함께 작동합니다.

메인 루프

버전 7 Unix의 원래 cron은 매우 간단하게 작동했습니다. 루프에서 구성을 다시 읽고, 현재 분의 작업을 수퍼유저로 시작하고, 다음 분이 시작될 때까지 잠자기 상태였습니다. 오래된 시스템에 대한 이 간단한 접근 방식에는 너무 많은 리소스가 필요했습니다.

SysV에서는 데몬이 작업이 정의된 가장 가까운 분까지 또는 30분 동안 절전 모드로 전환되는 대체 버전이 제안되었습니다. 이 모드에서는 구성을 다시 읽고 작업을 확인하는 데 소비되는 리소스가 적었지만 작업 목록을 빠르게 업데이트하는 것이 불편했습니다.

Vixie cron은 80분에 한 번씩 작업 목록을 확인하기 위해 돌아왔습니다. 다행스럽게도 XNUMX년대 말에는 표준 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 스타일로 실행됩니다. 즉, 작업을 비동기적으로 수행하기 위해 포크를 수행합니다. 상위 프로세스는 계속해서 작업을 시작하고 하위 프로세스는 작업 프로세스를 준비합니다.

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

child_process에는 꽤 많은 논리가 있습니다. 표준 출력 및 오류 스트림을 자체적으로 받아 메일로 보내고(MAILTO 환경 변수가 작업 테이블에 지정된 경우) 마지막으로 기본 메시지를 기다립니다. 작업을 완료하는 과정입니다.

작업 프로세스는 또 다른 포크로 구성됩니다.

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입니다. 예를 들어 원격 사용자에 대한 설명과 같은 몇 가지 흥미로운 세부 사항은 생략했지만 주요 내용은 간략하게 설명했습니다.

사후

Cron은 Unix 세계 최고의 전통을 바탕으로 만들어진 놀랍도록 간단하고 유용한 프로그램입니다. 그녀는 추가로 하는 일이 없지만 지금까지 수십 년 동안 자신의 일을 훌륭하게 해왔습니다. Ubuntu와 함께 제공되는 버전의 코드를 처리하는 데는 한 시간도 채 걸리지 않았고 정말 즐거웠습니다! 여러분과 공유할 수 있었으면 좋겠습니다.

나는 당신에 대해 모르지만, 지나치게 복잡하고 지나치게 추상적인 경향이 있는 현대 프로그래밍이 오랫동안 그러한 단순성에 도움이 되지 않았다는 것을 깨닫고 조금 슬프다.

cron에 대한 현대적인 대안이 많이 있습니다. systemd-timers를 사용하면 종속성이 있는 복잡한 시스템을 구성할 수 있고, fcron을 사용하면 작업별로 리소스 소비를 보다 유연하게 조절할 수 있습니다. 하지만 개인적으로 가장 간단한 crontab이면 항상 충분했습니다.

즉, Unix를 사랑하고 간단한 프로그램을 사용하며 플랫폼의 마나를 읽는 것을 잊지 마십시오!

출처 : habr.com