1분기

1분기

파일을 생성하여 크론 작업을 설정하려고 합니다 /etc/cron.d/myjob.

55 * * * * t echo hello > /tmp/cron.log  && cd /tmp/test/ && pwd > /tmp/cron.log

작업이 성공적으로 예약되었는지 확인하기 위해 리디렉션을 사용해 보았습니다. 21시 50분에 파일을 생성했는데 5분 뒤인 21시 55분에도 /tmp/cron.log가 아직 생성되지 않았습니다. 이유를 알고 싶습니다.

나는 사용자가 무엇을 원하는지 지정 t합니다 /etc/cron.d/myjob. 그런데 누구의 크론 작업인가요? 확실하지 않아서 아래 두 명령을 시도했습니다. 내가 만든 작업도 표시되지 않습니다.

$ crontab -l
no crontab for t
$ sudo crontab -l
[sudo] password for t: 
no crontab for root

내 /etc/crontab은 /etc/cron.d/ 아래의 파일을 명시적으로 읽지 않습니다. 아래를 참조하세요. 이것이 내 크론 작업이 실행되지 않는 이유일 수 있습니까? 감사해요.

# /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
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/myjob됩니다 . rw-r--r--내 작업 파일의 원래 rw-rw-r--권한이 작동하지 않지만 rw-r--r--필요한 이유는 무엇입니까? /etc/cron.d/아래의 파일은 /etc/cron.daily/동일한 권한을 가져야 합니까 rw-r--r--?

/etc/crontab파일을 명시적으로 읽을 필요가 없는 이유는 무엇 입니까 /etc/cron.d/?

답변1

1분기

내 작업 파일의 원래 rw-rw-r-- 권한이 작동하지 않는 이유는 무엇입니까?

에서 man cron:

/etc/crontab 및 /etc/cron.d의 파일은 루트가 소유해야 하며 그룹화하거나 쓰기가 가능하지 않습니다.

따라서 내부 파일은 다음 /etc/cron.d과 같아야 합니다.

chown root:root /etc/cron.d/*
chmod go-wx /etc/cron.d/*
chmod -x /etc/cron.d/*

2분기

/etc/crontab이 /etc/cron.d/ 아래의 파일을 명시적으로 읽을 필요가 없는 이유는 무엇입니까?

아니요, 그런 말은 아닙니다. 물론 man 5 crontab:

/etc/crontab: 시스템 전체 crontab 다른 crontab과 달리 이 파일과 /etc/cron.d의 파일을 편집할 때 새 버전을 설치하기 위해 "crontab" 명령을 실행할 필요가 없습니다. 이 파일에는 다른 crontab에는 없는 사용자 이름 필드도 있습니다.

이는 crontab -e새로운 cron 작업을 실행하지 않고도 편집하고 설치할 수 있음을 의미합니다. 아래 파일은 /etc/cron.d/다음 사용자가 읽고 해석했습니다.cron일단 편집했습니다. 그리고 여기에 정의된 작업은 crontab실행 파일을 호출하지 않고 예약된 대로 실행됩니다 .

경고하다

하지만 다음 내용도 읽어야 합니다 man cron.

일반적으로 시스템 관리자는 /etc/cron.d/를 사용하지 말고 표준 시스템 crontab /etc/crontab을 사용해야 합니다.

이는 crontab -ecron 작업을 생성하기 위해 실행하는 것을 의미합니다.

일반적으로, /etc/crontab직접 편집(또는 파일)하는 것은 좋지 않은 생각입니다. 특히 신규 사용자에게는 더욱 그렇습니다. /etc/cron.dcron 작업을 사용하고 관리하는 데 익숙해 crontab -e지면 crontab -l(오랜) 시간이 지나면 그것이 /etc/crontab수행하는 작업을 이해하려고 노력할 수 있습니다.

관련된


편집하다

당신이 묻는 이후 :

crontab -e가 /etc/cron.d/에서 cron 작업을 생성할 수 있습니까?

아니, 내 말은 그런 뜻이 아니었어. Cron 작업(사용자용)을 사용할 수 있습니다 /var/spool/cron/crontabs(Debian과 유사한 배포판에서). 여기가 crontab -e명령으로 편집되는 곳 입니다 .

일반적으로 (이전에) 편집되는 것은 작업 /etc/crontab이며 system, 설치된 소프트웨어 패키지(예: anacron)를 사용하여 자신의 작업을 예약합니다. 이 파일은 사용자가 편집해야 하는 파일이 아닙니다. Debian에는 파일 편집 시 오류를 방지하기 위해 새 작업을 추가할 수 있는 디렉터리가 있습니다( /etc/crontab). 그러나 이 디렉토리 /etc/cron.d/는 여전히 사용자(또는 관리자)가 수동으로 편집할 수 있는 디렉토리가 아닙니다.

이는 사용자에게 파일 /etc/sudoers을 편집하면 안 되는 이유를 묻는 것과 유사합니다.

물론, 사용자(루트)도 nano /etc/sudoers파일을 실행하고 변경할 수 있습니다. 시스템은 루트를 차단하지 않습니다. 그러나 이것은 "나쁜 생각"이다.

crontab 매뉴얼은 사용자가 아닌 개발자와 대화하기 위해 작성되었기 때문에 오해의 소지가 있습니다. 개발자가 이러한 파일에서 수행해야 할 작업을 설명합니다.

/etc/crontab관련: (또는 /etc/cron.d)을 추가해야 하는 이유 가 무엇이라고 생각하시나요 ?

이 두 위치의 파일에는 "줄"이 포함되어 있으며 각 줄은 작업입니다.
를 사용하여 편집한 줄은 완전히 동일합니다 crontab -e. 각 줄은 cron에 의해 실행되는 작업입니다. 유일한 차이점은 두 위치 모두에서 작업 행에 "사용자"라는 추가 필드가 포함되어 있다는 것입니다. 하지만:

crontab -u user1 -e

"user1"로 실행될 새 행(작업)도 추가됩니다(명령을 실행하는 사용자에게 올바른 권한이 있는 경우). 유일한(실질적인) 차이점은 사용자가 이러한 작업을 편집할 수 있지만 /etc/crontab또는 의 작업은 편집할 수 없다는 것입니다 /etc/cron.d/. 사용자가 다른 사용자의 작업을 편집하는 것을 방지하는 것이 나에게는 좋은 생각인 것 같습니다.

즉, 위치를 추가하십시오: 를 사용하십시오 crontab -e.

관련 정보