crontab과 /etc/cron.hourly, daily, weekly의 차이점

Subversion 저장소의 시간당 svnsync 백업을 수행하는 예약 된 스크립트가 있습니다. 루트 crontab의 항목에서 문제없이 실행했지만 추가 가시성을 위해 대신 /etc/cron.hourly에서 실행하고 싶다고 결정했습니다. 엔지니어가 실수로 crontab을 삭제했기 때문에 "crontab -r "은"crontab을 읽습니다 ;-))

cron.hourly 스크립트의 svnsync 명령은 모두 SVN 저장소의 SSL 인증서를 승인해야한다는 메시지와 함께 실패합니다 (이 메시지는 사용자가 SVN 저장소에 처음 액세스 할 때 대화식으로 표시되지만 인증서는 한 번만 표시됩니다) 메시지가 다시 나타나지 않습니다).

따라서 스크립트가 루트 crontab을 통해 실행될 때와 cron.hourly에서 실행될 때 다른 사용자 환경에서 스크립트가 실행되고있는 것 같습니다. 누구든지 차이점을 설명 할 수 있습니까?

업데이트 : 내 배포판에 대해 언급 했어야합니다 .CentOS 5.1에서 anacron을 사용하고 있습니다.

업데이트 2 : 지금까지 제안 해 주셔서 감사합니다. 나는 이것이 더 Subversion 질문으로 바뀌고 있다고 생각합니다. 나는 항상 내 환경을 스크립트로 캡슐화하려고 시도하지만 여기서 문제는 SVN에서 스크립트를 실행할 때 SSL 인증서를 수락하도록 요청하는 환경이 무엇인지 확실하지 않다는 것입니다. cron. 시간당. run-parts 스크립트가 실행되는 방식과 관련이 있다고 생각합니다.

'--config-dir'옵션을 사용하여 허용 된 인증서를 찾을 수있는 위치를 알려야합니다 (예 : 기본적으로 ~ / .subversion).

즉, 다른 곳 에서 제안한 것처럼 후크 / 커밋 후 스크립트에서 svnsync를 호출하는 것이 좋습니다 . 그런 다음 미러는 항상 한 시간 전의 마스터 위치와 동기화되지 않고 항상 동기화됩니다.

데비안 / 우분투 시스템에서 cron.daily | weekly | montly는 기본 crontab에서 시작됩니다.

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

또한 /etc/cron.d/에 crontab 조각을 넣을 수 있습니다.

보시다시피이 환경에는 특별한 것이 없습니다. 최소한 데비안 / 우분투에서는 모두 루트 계정으로 실행됩니다.

스크립트를 시작할 때 cron 스크립트를 작성할 때 항상 사용할 PATH 및 기타 환경 변수를 설정하므로 모든 환경에서 올바르게 작동하는지 확신 할 수 있습니다.

시스템 전체의 일반 crontab은 특정 사용자의 crontab이며로 사용되는 username 필드가 /etc/crontab있습니다.

/etc/cron.*(시간별, 일별, 주별, 월별) 에서 스크립트를 사용 하는 것은 root사용자를 위해 crontab을 구성하는 더 깨끗하고 쉬운 방법 (일반적인 구문 오류를 방지 함)이며 run-parts이는 디렉토리에서 스크립트 또는 프로그램을 실행 하여 처리됩니다 . 이러한 모든 규칙은 기본적으로 시스템 전체 crontab에 기본적으로 정의되어 /etc/crontab있으므로 ( ) 동일합니다.

cron 작업이에 의해 처리되는 run-parts경우 다음을 통해 정확히 어떤 스크립트를 실행할지 테스트 할 수 있으므로 디버그하기가 더 쉽습니다.

sudo run-parts --report --test /etc/cron.daily

내 첫 번째 추측은 HOME 변수를 확인하는 것입니다.

내 Centos 시스템에서 man 5 crontab은 다음과 같이 말합니다.

cron (8) 데몬이 여러 환경 변수를 자동으로 설정합니다. SHELL은 / bin / sh로 설정되고 LOGNAME 및 HOME은 crontab 소유자의 / etc / passwd 행에서 설정됩니다.

따라서 달리 지정하지 않으면 root의 crontab은 HOME에 / root를 사용합니다. 그러나 / etc / crontab (run-parts를 통해 /etc/cron.hourly가 실행되는 위치)에서 HOME은 /로 설정됩니다 (및 / bin / sh 대신 / bin / bash로 SHELL).

svnsync에 대해서는 모르지만 subversion은 ~ / .subversion / 디렉토리를 사용하므로 HOME에 따라 달라질 수 있습니다.

RHEL 5.1 시스템에서 PATH 환경 변수는 / etc / crontab에서 설정됩니다. 맨 위에있는 것은 환경에 공급되는 것입니다.

cron을 다시 시작하면 cron이 처음 실행될 때 (from /etc/crontab또는 or 인 경우 /var/spool/cron/$USER) / var / log / cron에이를 기록합니다. 그렇지 않으면 cron.hourly가 실행되었음을 알 수 있습니다.

내 crontab이 다음으로 설정되어 있습니다.

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

할 수있는 일은 다음과 같은 것을 /etc/cron.hourly에 넣는 것입니다.

env > /tmp/cron.env

그런 다음 파일이 올 때 검사하고 환경을 올바르게 설정하도록 스크립트를 수정하거나 (가능한 경우) crontab에서 호출 할 짧은 래퍼 스크립트를 작성하십시오.

/var/log/messages (또는 배포판에 상응하는)는 언제 어떤 사용자가 어떤 명령을 실행했는지에 대한 구체적인 내용을 알려줍니다.

환경에 어떤 것이 있다고 가정하지 마십시오. 항상 방어 적으로 코딩하십시오. 원하는 환경을 설정하는 모든 파일을 저장할 수있는 전체 파일이 있습니다. 그걸 써.

이식성이 많지는 않지만 마지막으로 (Debian에서) 확인했을 때 물건으로 패키지를 만들려면 cron.hourly (및 다른 것들)에 넣고 crontab에 직접 넣지 않는 것이 좋습니다.