웹서버 자동 실행 crontab(크론탭) 적용 시 문제점과 해결 방안

생소한 분야에서 익숙해지는 것은 정말 어렵습니다. 최근 서버를 나름 최적화하는데쉽지가 않습니다.

그동안 서버에서 정기적인 자동 실행을 해주는 crontab(크론탭)이 제대로 작동하지 않아서 몇주간 문제가 무엇인지 어떻게 해결해야 하는지 고민했는데요. 그 내용을 기록차 공유합니다. 누군가는 도움이 되라라고 믿으면서..

이와 관련해 많은 서칭을했지만 한국에서는 생각보다 일반인아니 초보자가 참고할만한 자세한자료가 없긴 합니다. 이 자료도 자세하지는 않지만 초심자입장에서 적어보았습니다.

예전 포스팅에서도 적었지만 crontab(크론탭)이 생각보다 까다로와서 작동되지 않은 경우가 많은데요. 이번에도 갑자기 작동이 안되어서 한 일주일을 헤매었습니다. 그 헤매면서 알게 되었던 내용들입니다.

이 내용은 리눅스 작업 Crontab(크론탭) 적용 스케줄러 및 오류 해결 방법과 전체적인 전체적인 맥락을 같이 하고 있습니다.

여기서는 구체적인 crontab(크론탭) 사용 설명은 따로 하지 않겠습니다.크론탭(crontab) 설치 및 설정에 대해서는 아래 글을 참조해주세요.

서버에서 자동 실행하는 crontab(크론탭) 설정 방법

Table of contents 목차 보이기

1. crontab(크론탭) 설정 – 2가지 방법의 유의 사항

crontab(크론탭)을 설정하는 방법에는 두가지가 있습니다.

첫째는 crontab -e 명령어를 사용해서 등록하는 것이구요. 이런 방식은 root가 작업하는 것으로 인지하므로 root 주체를 표기할 필요가 없습니다.

40 4 * * * mysqlcheck.sh

둘째는 /etc/crontab 파일에서 직접 등록하는 방법입니다. 이경우는 vi, nano와 같은 편집기로 crontab 파일을 열어서 편집을 합니다. 이는 작업 주체가 다양할 수 있기 때문에 반듯이 root 를 표기해 주어야 합니다.

40 4 * * * root mysqlcheck.sh

여기에서는 crontab -e를 사용하는 방법에서 나타나는 문제점등을 중심으로 설명드리겠습니다.

2. crontab(크론탭) 설정 시 유의 사항 몇가지

지금부터는 crontab(크론탭) 사용 시 주의점과 문제 해결 방법을 적어 봅니다.

2.1. 실행파일 sh는 복사하지 말것

crontab 설정 시 실행파일 sh 파일을 기존에 만들어 놓은 것을 FTP로부터 복사해 오는 경우가 있습니다 왜 그런지는 모르지만 이렇게 복사해오는 경우 제대로 작동하지 않습니다.
nano 편집기로 바로 만든 실행 파일은 정상적으로 작동하지만, 복사해온 실행 파일은 멀쩡히 해당 디렉토리에 존재하고 파일 권한도 충분하고 소유권도 root로 되어 있어 문제가 없어보이는데 Permission denied, not found같은 메세지를 내 보냅니다.

여러변 테스트를 통해서 내린 결론은 crontab 실행 파일은 서버 세팅 시 새로 만들어야겠다는 결론이었습니다.

조금 귀찮지만 sh 파일을 편지기를 사용해 다시 만들자구요.

2.2. 변경 후 반드시 cron 다시 실행시키기

crontab(크론탭) 명령을 등록 후 반드시 cron을 다시 실행해야 변경 내용에 제대로 반영됩니다.

service cron start  # 가동
또는 
service cron restart # 재가동

2.3. 실행 파일은 일반 경로에 위치, path 설정 – not found

cron은 보안때문에 사용자 개인 설정 파일을 참조하지 않습니다. 즉 사용자의 쉘 초기화 파일(.bashrc, .bash_profile)을 읽지 않습니다.
그러므로 실행 프로그램(예를 들어 *.sh)들은 /usr/bin이나 /bin과 같은 일반 경로에 있어야 cron이 제대로 찾아서 실행시킬 수 있습니다. 이런 경로에 없다면 /bin/sh: 1: /bin/dbbackup.sh: not found 같은 메세지가 메일로 보내집니다.

물론 실행 파일을 root에 놓는다면 문제는 없지만 다른 경로에 놓는 경우는 반듯이 참고해야 합니다.

From: root@root (Cron Daemon)
To: root@root
Subject: Cron <root@root> /bin/dbbackup.sh
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <path=/bin:/usr/bin:/usr/local/bin:/home>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

/bin/sh: 1: /bin/dbbackup.sh: not found

2.4. 실행 파일 권한 문제 – Permission denied

가끔 실행 파일에 제대로 권한이 성정되지 않았다면 아래와 같은 메세지가 메일로 보내집니다.

/bin/sh: 1: dbit.sh: Permission denied

그렇기 때문에 충분한 권한을 줍니다.

chmod +x dbbackup.sh

2.5. crontab 작동 확인 – service cron status

그리고 crontab이 제대로 작동하는지 확인하기 위해서 service cron status 명령을 사용합니다.

service cron status # checks if cron is running

그러면 아래와 같은 메세지를 보여줍니다.

# service cron status
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-01-17 03:17:19 KST; 17h ago
     Docs: man:cron(8)
 Main PID: 16188 (cron)
    Tasks: 3 (limit: 4915)
   Memory: 45.9M
      CPU: 5min 9.772s
   CGroup: /system.slice/cron.service
           ├─ 5389 /usr/sbin/CRON -f
           ├─ 5461 /usr/sbin/sendmail -i -FCronDaemon -B8BITMIME -oem root
           └─16188 /usr/sbin/cron -f

Jan 17 20:35:03 root sendmail[5293]: w0HBZ3GQ005293: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:
Jan 17 20:35:03 root CRON[5221]: pam_unix(cron:session): session closed for user root
Jan 17 20:35:03 root sendmail[5380]: My unqualified host name (happist) unknown; sleeping for retry
Jan 17 20:36:01 root CRON[5389]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 17 20:36:01 root CRON[5390]: (root) CMD (dbit.sh)
Jan 17 20:36:03 root sendmail[5380]: unable to qualify my own domain name (happist) -- using short name
Jan 17 20:36:03 root sendmail[5380]: w0HBa3Jw005380: from=root, size=418, class=0, nrcpts=1, msgid=<20180117113

10$ 제휴 프로모션으로 Vultr 가입하기