왜 crontab 스크립트가 작동하지 않습니까?

crontab일정에 따라 또는 예상대로 스크립트가 실행되지 않는 경우가 종종 있습니다. 그 이유는 여러 가지가 있습니다.

1. 잘못된 crontab 표기법
2. 권한 문제
3. 환경 변수

이 커뮤니티 위키는 crontab스크립트가 예상대로 실행되지 않는 주요 이유를 모으는 것을 목표로합니다 . 각 이유를 별도의 답변으로 작성하십시오.

답변 당 하나의 이유 (실행되지 않은 이유에 대한 세부 사항)를 포함시키고 해당 이유에 대한 수정 사항을 포함하십시오.

셸에서 예상대로 실행되지만 cron에서 잘못 실행하는 명령과 같은 cron 관련 문제 만 작성하십시오.

다른 환경

Cron은 최소한의 환경 변수 세트를 작업에 전달합니다. 차이점을 보려면 다음과 같이 더미 작업을 추가하십시오.

* * * * * env> /tmp/env.output

/tmp/env.output생성 될 때 까지 기다린 다음 작업을 다시 제거하십시오. 이제 일반 터미널에서 실행 /tmp/env.output결과와 내용을 비교하십시오 env.

여기서 일반적인 "gotcha"는 PATH환경 변수가 다릅니다. 아마 당신의 cron 스크립트는에서 somecommand찾은 명령 /opt/someApp/bin을 사용할 것 PATH입니다 /etc/environment. cron은 PATH해당 파일을 무시 하므로 somecommandcron으로 실행할 때 스크립트 실행 이 실패하지만 터미널에서 실행할 때는 작동하지 않습니다. 의 변수 /etc/environment가 cron 작업으로 전달 된다는 점은 주목할 가치 가 있습니다 PATH.

그 문제를 해결하려면 PATH스크립트 상단에 자신의 변수를 설정하십시오 . 예 :

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

일부는 모든 명령에 대한 절대 경로를 대신 사용하는 것을 선호합니다. 나는 그것을 반대하는 것이 좋습니다. 다른 시스템에서 스크립트를 실행하려는 경우 해당 시스템에서 명령이 /opt/someAppv2.2/bin대신 실행되는 경우를 고려하십시오 . 당신은 대체 전체 스크립트를 통해 가야 할 것 /opt/someApp/bin으로 /opt/someAppv2.2/bin대신 스크립트의 첫 번째 줄에 작은 편집을하는.

또한 crontab 파일에서 PATH 변수를 설정하면 모든 cron 작업에 적용됩니다. 예 :

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

내 최고 문제 : crontab파일 끝에 줄 바꿈을 추가하는 것을 잊어 버린 경우 . 즉, crontab 파일은 빈 줄로 끝나야합니다.

아래는이 문제에 대한 매뉴얼 페이지의 관련 섹션입니다 ( man crontab끝으로 건너 뛰기).

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Cron 데몬이 실행되고 있지 않습니다. 몇 달 전에이 문제를 해결했습니다.

유형:

pgrep cron 

숫자가 표시되지 않으면 cron이 실행되고 있지 않은 것입니다. sudo /etc/init.d/cron startcron을 시작하는 데 사용할 수 있습니다.

편집 : /etc/init.d를 통해 init 스크립트를 호출하는 대신 서비스 유틸리티를 사용하십시오.

sudo service cron start

편집 : 또한 현대 리눅스에서 systemctl을 사용할 수 있습니다.

sudo systemctl start cron

스크립트는에는 파일 이름 cron.d/, cron.daily/, cron.hourly/, 등, 점 (포함되지 않아야합니다 .그렇지 않으면 실행-부분을 건너 뛸 것입니다).

run-parts (8)를 참조하십시오.

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

당신이 크론 스크립트가 있다면 그래서 backup.sh, analyze-logs.pl에 cron.daily/디렉토리, 당신은 확장 이름을 제거하기 위해 최선을 것입니다.

많은 환경에서 cron은을 사용하여 명령을 실행 sh하지만 많은 사람들이 사용한다고 가정합니다 bash.

실패한 명령에 대해이를 테스트하거나 수정하기위한 제안 :

• 명령을 실행하여 sh작동하는지 확인하십시오.

  sh -c "mycommand"
  

• bash 서브 쉘에 명령을 랩하여 bash에서 실행되도록하십시오.

  bash -c "mybashcommand"
  

• crontab 상단에 쉘을 설정하여 bash에서 모든 명령을 실행하도록 cron에 지시하십시오.

  SHELL=/bin/bash
  

• 명령이 스크립트 인 경우 스크립트에 shebang이 포함되어 있는지 확인하십시오.

  #!/bin/bash
  

시간대에 문제가있었습니다. Cron은 새로운 설치 시간대로 실행되었습니다. 해결책은 cron을 다시 시작하는 것이 었습니다.

sudo service cron restart

스크립트에는 절대 경로를 사용해야합니다.

예를 들어 다음 /bin/grep대신에 사용해야합니다 grep.

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

대신에:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

쉘에서 실행될 때 동일한 명령이 작동하기 때문에 이것은 특히 까다 롭습니다. 그 이유는 사용자 cron와 동일한 PATH환경 변수 가 없기 때문입니다 .

crontab 명령에 %기호가 있으면 cron이 해석하려고합니다. 따라서 %날짜 명령에 대한 형식 스펙과 같은 명령을 사용하는 경우 이스케이프해야합니다.

그와 다른 좋은 점은 여기에 있습니다 :
http://www.pantz.org/software/cron/croninfo.html

Cron이 실행할 수없는 스크립트를 호출 중입니다.

chmod +x /path/to/scrip스크립트 를 실행 하면 실행 파일이되고이 문제를 해결해야합니다.

사용자의 비밀번호가 만료되었을 수도 있습니다. 루트 비밀번호조차도 만료 될 수 있습니다. tail -f /var/log/cron.log암호가 만료되면 cron이 실패하는 것을 볼 수 있습니다 . 다음을 수행하여 비밀번호가 만료되지 않도록 설정할 수 있습니다.passwd -x -1 <username>

cron에 대한 일부 시스템 (Debian, Ubuntu) 로깅은 기본적으로 활성화되어 있지 않습니다. 에서 /etc/rsyslog.conf 또는 /etc/rsyslog.d/50-default.conf 라인 :

# cron.*                          /var/log/cron.log

sudo nano /etc/rsyslog.conf주석 처리를 하지 않은 상태에서 편집 ( ) 해야합니다 .

cron.*                          /var/log/cron.log

그 후에는 다음을 통해 rsyslog를 다시 시작해야합니다

/etc/init.d/rsyslog restart

또는

service rsyslog restart 

출처 : 데비안 리눅스에서 crontab 로깅 활성화

일부 시스템 (Ubuntu)에서 cron에 대한 별도의 로깅 파일은 기본적으로 활성화되어 있지 않지만 cron 관련 로그는 syslog 파일에 나타납니다. 하나는 사용할 수 있습니다

cat /var/log/syslog | grep cron -i

cron 관련 메시지를 봅니다.

cronjob이 GUI 앱을 호출하는 경우 사용할 디스플레이를 알려 주어야합니다.

예 : cron으로 Firefox를 시작합니다.

스크립트는 export DISPLAY=:0어딘가에 있어야합니다 .

권한 문제는 상당히 흔합니다.

일반적인 해결 방법은 루트의 crontab을 사용하여 모든 것을 실행하는 것입니다. 적절한 권한을 설정하는 것은 분명히 간과되는 문제입니다.

안전하지 않은 크론 테이블 권한

권한이 안전하지 않은 경우 cron 테이블이 거부 됩니다.

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

문제는 다음과 같이 해결됩니다.

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

스크립트는 위치에 민감합니다. 이것은 스크립트에서 항상 절대 경로를 사용하는 것과 관련이 있지만 동일하지는 않습니다. cd실행하기 전에 cron 작업이 특정 디렉토리에 있어야 할 수도 있습니다 . 예를 들어 레일즈 애플리케이션의 레이크 작업은 올바른 데이터베이스를 언급하지 않고 Rake가 올바른 작업을 찾기 위해 애플리케이션 루트에 있어야 할 수도 있습니다.

그래서 crontab 항목은

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

로 더 나은 것

23 3 * * * cd / var / www / production / current && / usr / bin / rake db : session_purge RAILS_ENV = production

또는 crontab 항목을 더 단순하고 덜 부서지지 않게 유지하려면 다음을 수행하십시오.

23 3 * * * /home/<user>/scripts/session-purge.sh

다음 코드를 사용하여 /home/<user>/scripts/session-purge.sh:

cd / var / www / production / current
/ usr / bin / rake db : session_purge RAILS_ENV = 생산

과거에 작동했던 Crontab 사양 은 하나의 crontab 파일에서 다른 crontab 파일로 이동할 때 중단 될 수 있습니다. 때로는 시스템 크론 탭 파일에서 사용자 크론 탭 파일로 또는 그 반대로 스펙을 이동했기 때문입니다.

크론 작업 사양 형식은 사용자의 crontab 파일 (은 / var / spool / cron / 사용자 이름 또는 / var / spool / cron / crontabs 디렉토리 / 이름) 시스템의 크론 탭 (사이의 차이 /etc/crontab와 파일에서 /etc/cron.d).

시스템 크론 탭에는 명령 실행 직전에 추가 필드 'user'가 있습니다.

이로 인해 george; command not found명령을 /etc/crontab파일 밖으로 이동 하거나 파일을 /etc/cron.d사용자의 crontab 파일로 이동할 때 와 같은 오류가 발생 합니다.

반대로, cron은 /usr/bin/restartxyz is not a valid username반대로 발생할 때 유사하거나 유사한 오류를 전달 합니다.

cron 스크립트가 --verbose 옵션을 사용하여 명령을 호출합니다

스크립트를 입력하는 동안 자동 조종 장치에 있었고 --verbose 옵션을 포함했기 때문에 cron 스크립트가 실패했습니다.

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

셸에서 실행할 때는 스크립트가 제대로 실행되었지만 셸에서 실행할 때는 상세 출력이 stdout으로 이동하지만 crontab에서는 실행할 수 없으므로 crontab에서 실행할 때는 실패했습니다. 'v'를 제거하는 쉬운 수정 :

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

내가 cron이 잘못 표시된 일정으로 실패한 것을 가장 자주 본 이유는 무엇입니까? 오후 11시 15 분에 예약 된 작업 15 23 * * *을 * * 11 15 *또는 대신에 지정하는 것이 실제로 필요합니다 11 15 * * *. 자정 이후 작업에 대한 요일도 혼동됩니다. MF는 2-6자정 이후 가 아닙니다 1-5. 특정 날짜는 일반적으로 * * 3 1 *3 월 3 일이 아닌 거의 사용 하지 않으므로 문제가됩니다 . 확실하지 않은 경우 https://crontab.guru/ 에서 온라인으로 cron 일정을 확인하십시오 .

2/3시간 사양 과 같은 지원되지 않는 옵션을 사용하여 다른 플랫폼에서 작업하는 경우 에도 실패 할 수 있습니다. 이것은 매우 유용한 옵션이지만 보편적으로 사용 가능한 것은 아닙니다. 또한 같은 목록과 문제를 통해 실행 한 1-5나 1,3,5.

규정되지 않은 경로를 사용하면 문제점이 발생했습니다. 기본 경로는 일반적으로 /bin:/usr/bin표준 명령 만 실행됩니다. 이 디렉토리에는 일반적으로 원하는 명령이 없습니다. 비표준 명령을 사용하는 스크립트에도 영향을줍니다. 다른 환경 변수도 누락 될 수 있습니다.

기존 crontab을 완전히 지우면 문제가 발생했습니다. 이제 파일 사본에서로드합니다. 기존 crontab -l크론 탭이 클로버 될 경우이를 사용하여 복구 할 수 있습니다 . crontab의 사본을 ~ / bin에 보관합니다. 전체적으로 주석 처리되며 줄로 끝납니다 # EOF. 이것은 다음과 같은 crontab 항목에서 매일 다시로드됩니다.

#! / usr / bin / crontab
#이 crontab 새로 고침
#
54 12 * * * $ {HOME} / bin / crontab

위의 reload 명령은 crontab을 실행하는 뱅 경로가있는 실행 가능한 crontab에 의존합니다. 일부 시스템에서는 명령에서 crontab을 실행하고 파일을 지정해야합니다. 디렉토리가 네트워크 공유 인 경우 종종 crontab.$(hostname)파일 이름으로 사용 합니다. 이것은 잘못된 서버에 잘못된 crontab이로드 된 경우를 정정합니다.

파일을 사용하면 crontab의 백업을 제공하고 임시 편집 (사용할 때만 crontab -e)을 자동으로 제거 할 수 있습니다. 스케줄링 매개 변수를 올바르게 얻는 데 도움이되는 헤더가 있습니다. 경험이없는 사용자가 crontab을 편집 할 때 추가했습니다.

드물게 사용자 입력이 필요한 명령이 실행되었습니다. 일부는 입력 리디렉션으로 작동하지만 crontab에서는 실패합니다.

SSH 키를 통해 계정에 액세스하는 경우 계정에 로그인 할 수 있지만 계정의 비밀번호가 잠겨 있음을 알 수 없습니다 (예 : 만료 또는 유효하지 않은 비밀번호 시도로 인해)

시스템이 PAM을 사용 중이고 계정이 잠겨 있으면 cronjob이 실행되지 않을 수 있습니다. (필자는 솔라리스에서 테스트했지만 우분투에서는 테스트하지 않았습니다)

/ var / adm / messages에서 다음과 같은 메시지를 찾을 수 있습니다.

10 월 24 일 07:51:00 mybox cron [29024] : [ID 731128 auth.notice] pam_unix_account : cron이 로컬 호스트에서 잠긴 계정 myuser의 유효성을 검사하려고합니다.
10 월 24 일 07:52:00 mybox cron [29063] : [ID 731128 auth.notice] pam_unix_account : cron이 로컬 호스트에서 잠긴 계정 myuser의 유효성을 검사하려고합니다.
10 월 24 일 07:53:00 mybox cron [29098] : [ID 731128 auth.notice] pam_unix_account : cron이 로컬 호스트에서 잠긴 계정 myuser의 유효성을 검사하려고합니다.
10 월 24 일 07:54:00 mybox cron [29527] : [ID 731128 auth.notice] pam_unix_account : cron이 로컬 호스트에서 잠긴 계정 myuser의 유효성을 검사하려고합니다.

당신이해야 할 모든 실행 :

# passwd -u <USERNAME>

계정의 잠금을 해제하려면 루트로 사용하면 crontab이 다시 작동해야합니다.

다음과 같은 명령이있는 경우 :

* * * * * /path/to/script >> /tmp/output

작동하지 않으며 출력을 볼 수 없습니다. 반드시 cron이 작동하지 않는다는 의미는 아닙니다. 스크립트가 손상되어 출력이 stderr 로 이동 하고 / tmp / output으로 전달되지 않습니다. 이 출력도 캡처하여 그렇지 않은지 확인하십시오.

* * * * * /path/to/script >> /tmp/output 2>&1

이것이 문제를 파악하는 데 도움이되는지 확인하십시오.

=== 도커 경고 ===

도커를 사용하는 경우

나는 cron을 백그라운드에서 실행하도록 관리 할 수 ​​없다고 추가하는 것이 적절하다고 생각합니다.

컨테이너 내에서 cron 작업을 실행하기 위해 supervisor를 사용 cron -f하고 다른 프로세스와 함께를 실행했습니다 .

편집 : 또 다른 문제-HOST 네트워킹으로 컨테이너를 실행할 때 작동하지 않았습니다. https://github.com/phusion/baseimage-docker/issues/144 에서이 문제를 참조하십시오.

데이터베이스에서 오래된 트랜잭션 데이터를 제거하기 위해 다른 스크립트를 만드는 설치 셸 스크립트를 작성했습니다. 작업의 일부로 cron데이터베이스로드가 적을 때 임의의 시간에 매일 작업이 실행되도록 구성해야했습니다 .

나는 mycronjobcron schedule, username 및 command 로 파일 을 작성 하고 /etc/cron.d디렉토리에 복사했습니다 . 내 두 가지 문제 :

1. mycronjob 파일을 실행하려면 루트가 소유해야했습니다
2. 파일의 권한을 644-664로 실행하지 않도록 설정해야했습니다.

권한 문제는 /var/log/syslog다음과 비슷한 형태로 나타납니다 .

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

첫 번째 줄은 /etc/crontab파일을 가리키고 나중에는 아래에 놓인 파일을 가리 킵니다 /etc/cront.d.

crontab이 이해하지 못하는 방식으로 작성된 줄. 올바르게 작성해야합니다. 여기 CrontabHowTo 입니다.

Cron 데몬이 실행 중일 수 있지만 실제로 작동하지는 않습니다. cron을 다시 시작하십시오.

sudo /etc/init.d/cron restart

한 줄에 username 인수를 사용하여 "crontab -e"를 통해 cron에 쓰기 사용자 (또는 sysadmins)가 쉘 스크립트를 작성하고 왜 자동화하지 않는지 이해하지 못하는 예를 보았습니다. "user"인수는 / etc / crontab에 있지만 사용자 정의 파일에는 없습니다. 예를 들어 개인 파일은 다음과 같습니다.

# m h dom mon dow command

* * */2  *   *  /some/shell/script

반면 / etc / crontab은 다음과 같습니다.

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

그렇다면 왜 후자를 하시겠습니까? 권한 설정 방법에 따라이 과정이 매우 복잡해질 수 있습니다. 복잡한 내용을 이해하지 못하거나 준설에 신경 쓰고 싶지 않은 사용자를 위해 작업을 자동화하는 스크립트를 작성했습니다. 권한을로 설정 --x------하면 스크립트를 읽거나 실수로 변경하지 않고도 스크립트를 실행 가능하게 만들 수 있습니다. 그러나 하나의 파일에서 다른 여러 명령을 사용 하여이 명령을 실행하고 싶을 수 있으므로 유지 관리가 쉬워 지지만 파일 출력에 올바른 소유자가 지정되어 있는지 확인하십시오. (적어도 우분투 10.10에서) 이렇게하면 파일을 읽을뿐만 아니라 실행 할 수 없다는 플러스 (을 통해 갈 때 충분히 재미있게, 더 오류가 발생하지 않는,은 / etc / crontab을에서 기간을 가하고와 전에 언급 한 문제를 모두 중단 crontab -e) .

예를 들어, sudo crontab -e루트 권한으로 스크립트를 실행 chown username file_output하고 쉘 스크립트에서 해당 스크립트를 실행하는 데 사용되는 인스턴스를 보았습니다 . 조잡하지만 작동합니다. IMHO, 더 우아한 옵션은 /etc/crontab사용자 이름을 선언하고 적절한 권한을 부여 file_output하여 올바른 장소와 소유자에게 보내는 것입니다.

포함 된 명령의 기본 동작이 proc가 시작되면 화면에 한 줄 이상을 출력하는 경우 자세한 정보 표시 모드에 대해 Aaron Peart가 언급 한 내용을 기반으로 상세 정보 표시 모드가 아닌 스크립트가 초기화되지만 완료되지 않는 경우가 있습니다. 예를 들어, 파일을 원격 서버로 다운로드하거나 업로드하는 유틸리티 인 curl을 사용하는 인트라넷 용 백업 스크립트를 작성했으며 HTTP를 통해서만 원격 파일에 액세스 할 수 있으면 매우 편리합니다. 'curl http://something.com/somefile.xls '를 사용하면 내가 쓴 스크립트가 중단되고 줄 바꿈이 나오고 진행 줄이 생겨서 완료되지 않습니다. 자동 플래그 (-s)를 사용하여 정보를 출력하지 않도록 지시하고 파일을 다운로드하지 못한 경우 처리 할 고유 코드를 작성해야했습니다.

crontable에서 환경 변수를 정의 할 수 있지만 쉘 스크립트에는 없습니다. 따라서 다음과 같은 구성은 작동하지 않습니다.

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

이는 변수가 crontable에서 해석되지 않기 때문입니다. 모든 값은 문자 그대로 사용됩니다. 대괄호를 생략해도 마찬가지입니다. 따라서 명령이 실행되지 않고 로그 파일이 작성되지 않습니다 ...

대신 모든 환경 변수를 똑바로 정의해야합니다.

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

cron 내에서 작업이 실행되면 stdin이 닫힙니다. stdin의 사용 가능 여부에 따라 다르게 작동하는 프로그램은 쉘 세션과 cron에서 다르게 작동합니다.

goaccess웹 서버 로그 파일을 분석하기위한 프로그램이 그 예입니다 . cron에서는 작동하지 않습니다.

goaccess -a -f /var/log/nginx/access.log > output.html

그리고 goaccess대신 보고서를 만드는의 도움말 페이지를 보여줍니다. 쉘에서 이것은 다음과 같이 재현 될 수 있습니다

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

해결 goaccess방법은 파일을 읽지 않고 stdin에서 로그를 읽도록하는 것이므로 해결책은 crontab 항목을 다음과 같이 변경하는 것입니다.

cat /var/log/nginx/access.log | goaccess -a > output.html

제 경우에는 cron과 crontab의 소유자가 다릅니다.

작동하지 않는 나는 이것을 가지고 있었다 :

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

기본적으로 cron-config를 실행하고 질문에 올바르게 대답해야했습니다. 내 '사용자'계정에 Win7 사용자 비밀번호를 입력해야하는 시점이 있습니다. 내가 읽은 것에서 이것은 잠재적 인 보안 문제인 것처럼 보이지만 단일 홈 네트워크의 유일한 관리자이므로 문제가 없다고 결정했습니다.

다음은 명령 시퀀스입니다.

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

내 RHEL7 서버에서 루트 크론 작업은 실행되지만 사용자 작업은 실행되지 않습니다. 홈 디렉토리가 없으면 작업이 실행되지 않는다는 것을 알았습니다 (그러나 / var / log / cron에 좋은 오류가 표시됩니다). 홈 디렉토리를 만들 때 문제가 해결되었습니다.

Windows 편집기 (삼바 등을 통해)를 사용하여 crontab 파일을 편집하고 개행을 \ n \ r 또는 \ r로 바꾸면 cron이 실행되지 않습니다.

또한 /etc/cron.d/*를 사용 중이고 해당 파일 중 하나에 \ r이 있으면 cron은 파일을 이동하여 잘못된 파일에 도달하면 중지합니다. 그것이 문제인지 확실하지 않습니까?

사용하다:

od -c /etc/cron.d/* | grep \r