crontab이 제대로 실행되지 않는다면 crontab에서 지원하지 않는 명령일 수 있습니다. (pushd, popd 명령 사용 불가)

개구리는 올챙이 적을 생각하지 못한다는 속담이 있습니다. 개발자도 마찬가지입니다. 원숙한 SW개발자가 되면 큰 어려움 없이 새로운 것을 배울 수 있고, 문제를 만나도 빨리 해결할 수 있습니다. 내가 개구리가 되어서 쉽게 과제를 진행하고 쉽게 문제를 풀 수 있겠지만, 그 모든 것들을 쉽게 익힐 수 있었던 것은 아니라는 것을 명심해야 하겠지요. 평소에 익숙하게 사용하던 crontab이 제대로 실행되지 않아서 시간과 노력을 제법 낭비했습니다. 결론부터 말씀드리자면, crontab에서 실행할 수 없는 명령어들이 존재합니다.

이 글에서는 crontab에서 실행할 수 없는 명령어인 pushd를 사용하여 강제로 crontab이 제대로 실행될 수 없도록 하고, 그 상황에서 디버깅을 하는 방법에 대해서 설명하고자 합니다. 이 글이 crontab이 제대로 실행되지 않아서 짜증이 올라오는 개발자들에게 조금이라도 도움이 되었으면 합니다.

 

crontab 디버깅 개요

리눅스에서 주기적으로 무언가를 실행시키고 싶다면 crontab이라는 것을 사용하면 됩니다. 이 글을 읽으시는 분들께서는 crontab에 대한 개념과 사용법에 대해서 익숙하신 분들이므로 crontab의 개념과 사용법에 대해서는 생략하겠습니다. 일반적인 스크립트는 디버그 메시지를 추가하면서 실행시켜볼 수 있습니다. 하지만 crontab은 실행 도중에 에러가 발생할 경우 그 내용을 살펴보기가 다소 불편합니다.

여기까지 글을 읽으시면서 "훗! 리다이렉션을 해서 로그를 보면 되잖아?"라고 하실 수 있겠습니다. 맞는 말이면서도 틀린 말입니다. 이 글에서는 리다이렉션만으로 crontab이 동작하지 않는 상황을 강제로 만들어서 디버깅을 하는 방법에 대해서 설명드리겠습니다.

 

정상적으로 동작하는 crontab 예제

우선 테스트를 위해서 아래와 같이 간단한 배쉬 스크립트를 먼저 작성하겠습니다.

#!/bin/bash

date >> date.txt

 

위의 스크립트가 매분마다 실행될 수 있도록 crontab -e 명령으로 설정하고 1분을 기다려보겠습니다. 

* * * * * cd /home/user/test; ./crontab.sh

 

위와 같이 설정하고 1분을 기다린 후에 date.txt 파일을 열어보면 crontab이 제대로 실행되어 날짜 정보가 추가가 됩니다.

$ cat date.txt 
2022. 05. 26. (목) 12:37:01 KST

 

실행되지 않는 crontab 예제

이번에는 crontab에서 실행되는 cd 명령 대신 pushd 명령으로 바꿔보겠습니다. 참고로 pushd 명령과 popd 명령으로 bash shell script에서 문제없이 잘 사용되는 명령어들입니다. cd 명령의 경우 이전 디렉토리로 돌아가고 싶을 경우에 어디로 돌아가야되는지 모르는 반면, pushd 명령과 popd 명령은 이전 디렉토리로 손쉽게 돌아갈 수 있기 때문에 bash script에서 자주 활용되는 명령입니다.

 

기존

* * * * * cd /home/user/test; ./crontab.sh

 

변경

* * * * * pushd /home/user/test; ./crontab.sh

 

위와 같이 cd 명령을 pushd 명령으로만 바꿨는데 잘 동작하던 crontab이 제대로 동작하지 않기 시작합니다. date.txt 파일을 열어봐도 내용이 전혀 바뀌지 않습니다.

 

디버깅 #1. 리다이렉션

만약 crontab이 제대로 실행되지 않는다면 여러분들은 리다이렉션을 생각하실 것입니다.

 

기존

* * * * * pushd /home/user/test; ./crontab.sh

 

변경

* * * * * pushd /home/user/test; ./crontab.sh >> log.txt

 

위와 같이 리다이렉션을 통해서 crontab 실행 결과를 log.txt 파일로 생성하도록 변경해도 log.txt 파일이 생성되지 않습니다. crontab.sh 스크립트가 동작이 되어야 log.txt 파일이 생성됩니다. 이전 명령인 pushd 명령에서 에러가 발생하면 crontab.sh 스크립트가 수행되지 못하기 때문에 당연히 log.txt 파일도 생성이 안되는 것입니다.

우선 위의 문제는 pushd 명령을 crontab에서 수행할 수 없기 때문이라는 것을 우리는 알고 있습니다. 그럼 이 답답한 상황에서 어떻게 디버깅을 해야 할까요?

 

디버깅 #2. crontab 로그 분석

crontab이 실행되지 못하고, 그 피드백도 없다면 얼마나 무책임한 것일까요? 그렇지 않습니다. crontab이 제대로 실행되지 않으면 crontab은 나름대로 최선을 다해서 이것을 알려주려고 노력합니다. 관련 내용을 메일로 전송하려고 시도도 하고, 로그도 남깁니다. 우리가 그것을 살펴볼줄 모르는 것 뿐입니다.

 

그렇다면 crontab 로그는 어디에 남는 것일까요? 그건 시스템마다 다르다고 할 수 있습니다. 많은 사람들이 가장 먼저 dmesg 명령으로 crontab 로그를 찾으려고 시도해볼지도 모릅니다.

 

$ sudo dmesg | grep cron

위와 같이 dmesg 명령으로 crontab 로그를 찾아보려고해도 보이지 않습니다.

 

그러면 도대체 crontab 관련 로그는 어디에 생성되는 것일까요? 아래의 명령으로 crontab 관련 로그가 어디에 생성되도록 설정했는지 살펴봅니다.

$ cat /etc/rsyslog.d/50-default.conf | grep cron
#cron.*				/var/log/cron.log

 

필자의 경우 #cron.* /var/log/cron.log 로 주석처리 되어 있는 것을 확인할 수 있습니다. 만약 cron.* 설정이 주석처리되어 있지 않는다면 해당 파일(/var/log/cron.log)에 로그가 생성되겠지요.

 

crontab에 대한 로그 파일을 따로 지정하지 않았기 때문에 /var/log/syslog 파일에 crontab 로그가 남겠습니다.

May 26 12:36:01 desktop CRON[21495]: (user) CMD (pushd /home/user/test/crontab; ./crontab.sh) May 26 12:36:01 desktop sSMTP[21497]: Unable to locate mail May 26 12:36:01 desktop sSMTP[21497]: Cannot open mail:25 May 26 12:36:01 desktop cron[21497]: sendmail: Cannot open mail:25 May 26 12:36:01 desktop CRON[21494]: (user) MAIL (mailed 65 bytes of output but got status 0x0001 from MTA#012)

위의 로그를 살펴보면 crontab이 메일 전송을 시도했다는 것을 확인하실 수 있습니다. crontab의 경우 정상적으로 실행되면 메일을 전송하지 않고, 실패할 경우에만 메일 전송을 시도하기 때문에 crontab 실행이 실패했다는 것을 알 수 있습니다.

 

디버깅 #3. 메일 설정

보내는 메일 설정을 해두시면 crontab 실패시에 메일로 전송이 됩니다. 이 부분에 대해서는 추후에 기록할 예정입니다.

 

결론

crontab이 제대로 실행되지 않는 경우 아래 사항들을 체크해보시면 되겠습니다.

• 실행 결과를 리다이렉션하여 원인을 분석하는 방법
• /var/log/cron.log 로그 파일 확인
• /var/log/syslog 로그 파일 확인
• 보내는 메일 설정하여 수행 결과를 메일로 받아보는 방법

 

이상입니다.