/ etc / crontab을 편집하거나 crontab -e를 루트로 실행해야합니까?

43

루트로 실행해야하는 정기적 인 시스템 유지 관리 작업을 설정하고 있습니다. 나는 우분투 14.04 LTS와 함께 제공되는 cron의 풍미를 기본값으로 사용할 계획입니다.

이전 관리자 (회사를 떠난 이후)가 / etc / crontab을 직접 편집 한 것을 볼 수 있습니다. 그러나 다른 가능한 방법은 crontab -e루트 로 사용 하는 것입니다. 둘 중 하나를 사용하라는 설득력있는 주장이 있습니까?

linux cron ubuntu-14.04

— marcv81
소스

9

나에게 이것은 합법적 인 모범 사례 질문처럼 보이며 닫히지 않기를 바랍니다. 나는 이미 답변에서 관련되고 사실적인 요점을 확인하고 이에 대한 언급을 볼 수 있습니다.

— MadHatter

1

한 번 crontab -l (crontab을 나열하기 위해)을 입력했지만 crontab-;을 입력했습니다. 실수로 내 crontab을 삭제했습니다. 나는 그날 많은 것을 배웠다.

— Lumberjack

64

개인 crontab ( crontab -e)의 작업은 항상 소유자로 실행되며 여기 /etc/crontab에는 <user>관리자가 루트가 아닌 사용자로 실행되도록 작업을 구성 할 수있는 추가 필수 필드 가 포함되어 있습니다 .

시스템 crontab을 편집하거나 root에 대한 개인 crontab을 설정하는 것은 약간 더 이식성이 뛰어나고 특정 Linux 배포판에 국한되지 않고 개인 이 단일 파일로 모든 작업을 유지 하기가 더 편리 할 것입니다 .

개인적으로 나는 세 번째 옵션을 선호합니다 : 예약 된 각 작업 드롭마다

/etc/cron.d/크론 스 니펫이 포함 된 파일
관련 /etc/cron.[hourly |daily |weekly |monthly]디렉토리 의 실행 파일 (스크립트)

스크립트를 작성하는 것이 더 쉽고 (단순히 이러한 파일을 작성 / 덮어 쓰기 / 삭제할 수 있으며 단일 crontab 파일의 내용을 다루지 않아도 됨) 구성 관리 도구와 잘 작동하며 패키지 관리자는 이미 어쨌든.

작업 / 스크립트 /etc/cron.[hourly |daily |weekly |monthly]는 항상 루트로 실행됩니다. 여기서 크론 스 니펫은 /etc/cron.d/사용자 정의 일정을 설정하고에서와 동일한 필수 <user>필드를 가진 다른 사용자로 실행할 수 있습니다 /etc/crontab.

— HBruijn
소스

18

편집의 단점은 패키지 /etc/crontab를 업데이트 할 때마다 병합이 필요하다는 것 cron입니다. /etc/cron.*디렉토리 중 하나에 새 파일을 추가하면 문제가 없습니다 .

— kasperd

1

당신은 대부분의 배포판에 있음을 추가해야 /etc/cron.[hourly |daily |weekly |monthly]보유하고 실행을 하면서 /etc/cron.d크론 탭을 보유하고 있습니다. 그 외에는 +1입니다.

— GnP

나는 cron. [timing] 디렉토리의 팬이다. commn 옵션보다 더 세분화 된 것이 거의 필요하지 않다. 일부 배포판, 특히 Ubuntu는 이러한 폴더에 파일 확장자가있는 스크립트를 자동으로 무시합니다 (대부분의 사람들은 최근 배포판에서 수정되었을 수있는 .sh를 추가한다는 점을 고려하면 상당히 인터넷을 끄는 버그입니다). 해당 상황에서 스크립트가 작동하지 않는 이유를 해결하기가 매우 어렵습니다. 최소한 crontab에 추가하는 것이 보장됩니다.

— Gargravarr

15

내가 기억하는 가장 좋은 crontab -e점은 crontab 구문을 설치하기 전에 구문을 확인하고 실수하면 실수를하고 이전을 복원한다는 이점이 있습니다. 이런 식으로, 구문이 틀리면 이전에 작동했던 모든 것이 갑자기 멈추지 않습니다. 최선의 방법은 직접 visudo편집 하는 대신 실행 하는 것과 같은 유틸리티를 사용하는 것 /etc/sudoers입니다.

— 가 그라 바르
소스

2

+1 구문 유효성 검사에 대한 좋은 점입니다. 일부 구문 오류를 인식하지만 완벽하지는 않습니다 (즉 /etc/crontab, 6 번째 열에 사용자 이름이 있는 행 을 입력 할 수 있음 ). -대화식 도구를 사용하는 것이 "모범 사례" 가 아니라고 주장하고 싶지만 Puppet / Salt / Ansible 등과 같은 도구를 사용하여 자동화해야하며 더 이상 서버를 손으로 구성해서는 안됩니다. 반면에 당신이 구식이라면 실제로 도구를 사용하십시오.

— HBruijn

5 대 이상의 서버를 구성 할 경우 Ansible과 다른 서버가 유용하지만 1 번의 번거 로움은 없습니다. 단 하나의 서버로 Ansible 스크립트를 사용하면 2 년 동안 실패 할 때 동일하게 다시 빌드 할 수 있지만 이 시점에서 배포 / 저장소 변경으로 인해 스크립트가 더 이상 작동하지 않을 수 있습니다.

— marcv81

이것이 내가 받아 들인 대답에 격렬하게 동의하지 않는 이유입니다. 변경 사항이 무엇이든이 유효성 검사 프로세스를 통해 한 번 이상 실행해야합니다. 그런 다음 새로운 crontab에서 한 줄을 복사하여 다른 서버로 전파하기 위해 자동화 된 도구로 제공하는 경우 두 방법 모두 최고입니다.

— Monty Harder

스크립트를 시작할 때 도움이되지 않고 스크립트에 오류가 있으므로 드라 이런 테스트가 필요합니다.

— mckenzm

@mckenzm 동의하지만, 당신이 적용 할 수있는 바보 교정이 너무 많습니다 :)

— Gargravarr

2

그것은 실제로 스타일 질문입니다 .OS가 여러 방법을 제공하는 이유가 있습니다. 다른 사람 (또는 시스템을 다루지 않은 시간이 지난 후)을 혼동하지 않으려는 경우 일관되고 일관성이 없으며 일치하지 마십시오. 호스트 전체에서 실제로 어떤 작업이 예약되어 있는지 확인하기 어려운 경우 불쾌한 놀라움으로 끝나기 위해.

— rackandboneman
소스

2

특정 사용자 권한이 필요한 cron 작업을 추가하려면 다음 명령을 개인적으로 사용하십시오.

 # crontab -u <user> -e

당신도 추가 할 수 있습니다 sudo.

@rackandboneman이 언급했듯이 /etc/cron.d/ 파일을 망칠 필요가 없습니다. 문제가 사용자의 크론 작업에 관한 것이라면 crontab명령 기능을 사용하십시오 .

— aesnak
소스

3

-1 위의 작업의 가장 큰 단점은 사용자가 cronjob을 수정 / 삭제 / 중단 할 수 있다는 것입니다. 이는 일반적으로 관리자가 소중한 시간을 설정하는 데 소비했을 때 바람직하지 않습니다 ... 사용자가 서비스 계정이고 해당 계정이 잠기거나 만료 된 경우 서비스는 계속 실행되지만 잠긴 계정에 대한 개인 크론 탭은 일반적으로 비활성화됩니다.

— HBruijn

여기에 지정된 사용자가 공용 터미널 서비스 환경의 구성원과 같은 공용 사용자 인 경우 귀하가 맞습니다. 그러나 문제가 서비스 / 에이전트 사용자에 관한 것이라면 ... 다시 생각하면, 스타일에 관한 것입니다.

— aesnak