帮助中心

적용 환경과 사전 주의사항

가장 먼저 확인할 항목

Cron 작업이 실행되지 않는다고 판단하기 전에 작업이 등록된 사용자와 예상 실행 시각을 먼저 확인합니다. 표준 Cron 작업은 예약 시각에 서버가 꺼져 있으면 이후 부팅 시 자동으로 소급 실행되지 않습니다. 매일·매주처럼 실행 누락을 보완해야 하는 작업은 Anacron 사용 여부도 함께 확인해야 합니다.

1. 현재 서버 시간이 정확한지 확인합니다.
2. crond 서비스가 실행 중인지 확인합니다.
3. 작업이 어느 사용자 또는 어느 시스템 crontab에 등록되어 있는지 확인합니다.
4. /var/log/cron에서 해당 시각에 작업 실행 기록이 있는지 확인합니다.
5. 실행 기록은 있는데 결과가 없다면 스크립트, 환경 변수, 권한과 출력 경로를 점검합니다.

현재 시각과 시간대는 다음 명령어로 확인합니다.

date
timedatectl status

예상한 시간대와 서버의 Time zone이 다르면 작업이 고장 난 것이 아니라 다른 시각에 실행되고 있을 수 있습니다. 시간대를 수정한 경우에는 다음 예약 시각을 기준으로 다시 확인하십시오.

crond 서비스와 Cron 로그 확인

1. cronie 패키지 설치 여부 확인

CentOS 7의 반복 작업 예약 기능은 일반적으로 cronie 패키지가 제공합니다. 다음 명령어로 설치 여부와 버전을 확인합니다.

rpm -q cronie crontabs

패키지가 설치되어 있지 않다면 저장소 상태를 확인한 후 설치합니다. CentOS 7은 지원 종료 상태이므로 기존 미러가 아닌 Vault 저장소 구성이 필요할 수 있습니다.

yum install -y cronie crontabs

2. crond 서비스 상태와 자동 시작 확인

서비스가 중지되어 있거나 부팅 시 자동 시작이 해제되어 있으면 등록된 작업이 실행되지 않습니다.

systemctl status crond --no-pager -l
systemctl is-active crond
systemctl is-enabled crond

is-active 결과는 active, is-enabled 결과는 일반적으로 enabled여야 합니다. 서비스가 중지되어 있다면 현재 세션에서 시작하고 부팅 시 자동으로 시작하도록 설정합니다.

systemctl enable crond
systemctl start crond

시작이 실패하면 systemd 저널에서 원인을 확인합니다.

journalctl -u crond -b --no-pager -n 100

3. /var/log/cron에서 실행 기록 확인

CentOS 7에서는 Cron 관련 메시지가 일반적으로 /var/log/cron에 기록됩니다. 최근 기록과 실시간 기록을 각각 확인합니다.

tail -n 100 /var/log/cron
tail -f /var/log/cron

특정 사용자나 명령어를 찾을 때는 다음과 같이 검색합니다.

grep 'admin_user' /var/log/cron
grep 'my-job.sh' /var/log/cron

Cron 로그 자체가 갱신되지 않으면 rsyslog 서비스도 확인합니다.

systemctl status rsyslog --no-pager -l
systemctl is-active rsyslog

작업 등록 위치와 문법 확인

CentOS 7의 Cron 작업은 등록 위치에 따라 문법이 다릅니다. 가장 흔한 오류는 사용자 crontab에 사용자명 필드를 추가하거나, 반대로 /etc/crontab 또는 /etc/cron.d/ 파일에서 실행 사용자 필드를 누락하는 것입니다.

1. 사용자 crontab 확인

현재 로그인한 사용자의 작업을 확인합니다.

crontab -l

root 권한으로 특정 사용자의 작업을 확인할 때는 사용자명을 명시합니다.

crontab -u admin_user -l

작업을 root crontab에 등록한 것으로 생각했지만 실제로 일반 사용자 crontab에 등록했거나 그 반대인 경우가 많습니다. sudo crontab -e는 root의 crontab을 편집하므로 현재 사용자의 crontab -e와 다른 파일입니다.

2. 시스템 crontab과 /etc/cron.d 확인

sed -n '1,200p' /etc/crontab
find /etc/cron.d -maxdepth 1 -type f -printf '%M %u:%g %p\n'

/etc/cron.d/의 파일은 /etc/crontab과 동일하게 시간 필드 뒤에 실행 사용자명이 있어야 합니다. 예를 들어 매일 오전 2시에 admin_user 권한으로 실행하려면 다음 형식을 사용합니다.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * admin_user /usr/local/bin/my-job.sh >> /home/admin_user/my-job.log 2>&1

3. 숨은 문자와 마지막 줄바꿈 확인

Windows에서 작성한 파일은 CRLF 줄바꿈이나 보이지 않는 문자가 포함될 수 있습니다. 다음 명령어로 줄 끝 문자를 표시합니다.

sed -n 'l' /etc/cron.d/my-job

줄 끝에 ^M에 해당하는 \r 문자가 보이면 파일을 백업한 뒤 Unix 줄바꿈으로 변환합니다.

cp -a /etc/cron.d/my-job /etc/cron.d/my-job.backup
sed -i 's/\r$//' /etc/cron.d/my-job

crontab의 마지막 명령줄은 줄바꿈 문자로 끝나도록 저장하는 것이 안전합니다. 직접 /var/spool/cron/ 파일을 수정하지 말고 crontab -e 또는 crontab -u 사용자명 -e를 사용하십시오.

명령어·환경 변수·실행 권한 확인

1. 명령어와 파일 경로를 절대 경로로 지정

Cron은 로그인 셸과 동일한 환경을 사용하지 않습니다. 터미널에서 php, python, mysqldump처럼 명령어 이름만으로 실행되더라도 Cron에서는 PATH에 해당 디렉터리가 없어 실패할 수 있습니다.

실제 명령어 경로를 확인합니다.

command -v bash
command -v php
command -v python
command -v mysqldump

crontab에서는 확인된 절대 경로를 사용합니다.

0 2 * * * /usr/bin/php /home/admin_user/app/artisan schedule:run >> /home/admin_user/cron.log 2>&1

2. 필요한 환경 변수를 crontab 또는 스크립트에 명시

Cron은 기본적으로 제한된 환경에서 실행되며 사용자 홈의 .bash_profile이나 .bashrc를 자동으로 읽는다고 가정하면 안 됩니다. 필요한 PATH, 애플리케이션 환경 변수, 작업 디렉터리를 명시적으로 설정합니다.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOME=/home/admin_user

*/5 * * * * cd /home/admin_user/app && /usr/bin/php artisan schedule:run >> /home/admin_user/cron.log 2>&1

로그인 셸과 비슷한 환경을 강제로 불러오기 위해 무조건 source ~/.bash_profile을 추가하기보다 작업에 실제로 필요한 값만 명시하는 편이 예측 가능하고 안전합니다.

3. 스크립트 권한과 셔뱅 확인

스크립트 파일의 소유자, 실행 권한과 첫 줄을 확인합니다.

ls -l /usr/local/bin/my-job.sh
head -n 1 /usr/local/bin/my-job.sh
file /usr/local/bin/my-job.sh

Bash 스크립트라면 첫 줄을 다음과 같이 지정하고 실행 권한을 부여할 수 있습니다.

#!/bin/bash

chmod 750 /usr/local/bin/my-job.sh
bash -n /usr/local/bin/my-job.sh

bash -n이 메시지 없이 종료되면 Bash 문법상 큰 문제는 발견되지 않은 것입니다. 다만 외부 명령 실패, 권한 부족, 네트워크 오류까지 검증하는 명령은 아니므로 실제 실행 테스트가 필요합니다.

4. Cron과 유사한 최소 환경에서 수동 실행

root 권한에서 admin_user의 환경을 최소화한 상태로 실행하여 Cron 환경 차이를 재현합니다.

runuser -u admin_user -- env -i \
HOME=/home/admin_user \
USER=admin_user \
LOGNAME=admin_user \
SHELL=/bin/sh \
PATH=/usr/bin:/bin \
/bin/sh -c '/usr/local/bin/my-job.sh'

이 테스트에서 실패하면 Cron 예약식보다 스크립트 경로, 환경 변수, 권한 또는 작업 디렉터리를 먼저 수정해야 합니다.

5. 표준 출력과 오류를 파일에 기록

실패 원인을 확인할 수 있도록 명령 뒤에 표준 출력과 표준 오류 리디렉션을 추가합니다. 일반 사용자가 쓸 수 없는 /var/log 대신 해당 사용자의 홈 디렉터리를 사용하는 예시입니다.

*/5 * * * * /usr/local/bin/my-job.sh >> /home/admin_user/my-job.log 2>&1

작업 실행 후 로그를 확인합니다.

tail -n 100 /home/admin_user/my-job.log

6. 명령 안의 % 기호 이스케이프

crontab 명령 부분의 퍼센트 기호(%)는 특별한 의미를 가질 수 있으므로 date +%F 같은 표현은 백슬래시로 이스케이프합니다. 따옴표 안에 있어도 안전하게 이스케이프하는 것이 좋습니다.

0 0 * * * /usr/bin/date '+\%F \%T' >> /home/admin_user/date.log 2>&1

사용자 권한과 SELinux 확인

1. 실행 사용자와 대상 파일 권한 확인

Cron 작업은 등록된 사용자 권한으로 실행됩니다. 해당 사용자가 스크립트를 읽고 실행할 수 있으며 입력 파일과 출력 디렉터리에 필요한 권한을 갖는지 확인합니다.

id admin_user
namei -l /usr/local/bin/my-job.sh
namei -l /home/admin_user/output

namei -l은 경로를 구성하는 상위 디렉터리의 권한까지 표시하므로 파일 자체 권한은 정상인데 상위 디렉터리 접근이 차단된 경우를 찾는 데 유용합니다.

2. cron.allow와 cron.deny 확인

/etc/cron.allow가 존재하면 파일에 등록된 사용자만 crontab 사용이 허용됩니다. /etc/cron.allow가 없고 /etc/cron.deny가 존재하면 해당 파일에 등록된 사용자가 제한됩니다.

ls -l /etc/cron.allow /etc/cron.deny 2>/dev/null
grep -x 'admin_user' /etc/cron.allow 2>/dev/null
grep -x 'admin_user' /etc/cron.deny 2>/dev/null

접근 제어 파일을 수정할 때는 사용자명을 한 줄에 하나씩 정확히 입력합니다. 불필요하게 모든 사용자를 허용하지 말고 실제 Cron 작업이 필요한 계정만 관리하십시오.

3. crontab 파일 권한과 소유자 확인

Cronie는 보안상 소유자 이외의 사용자가 쓸 수 있는 crontab 파일을 거부할 수 있습니다. 사용자 crontab은 직접 고치지 말고 등록 상태를 확인한 뒤 crontab -e로 다시 저장합니다.

ls -ldZ /var/spool/cron
ls -lZ /var/spool/cron/admin_user

/etc/cron.d/에 직접 만든 파일은 일반적으로 root 소유로 두고 다른 사용자가 쓰지 못하도록 설정합니다.

chown root:root /etc/cron.d/my-job
chmod 644 /etc/cron.d/my-job

4. SELinux 차단 로그 확인

파일 권한이 정상인데도 특정 경로, 네트워크 자원 또는 애플리케이션 접근이 거부되면 SELinux AVC 로그를 확인합니다.

getenforce
ausearch -m AVC,USER_AVC -ts recent | tail -n 100

crontab이나 주기 실행 디렉터리를 다른 서버에서 복사한 뒤 SELinux 컨텍스트가 달라진 경우에는 기본 컨텍스트를 복원합니다.

restorecon -Rv /var/spool/cron /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

문제 확인을 위해 SELinux를 영구적으로 비활성화하는 방식은 권장하지 않습니다. AVC 로그에서 차단된 경로와 동작을 확인하고 파일 위치, 컨텍스트 또는 필요한 정책을 수정하십시오.

cron.daily와 run-parts 작업 확인

/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/에 넣은 스크립트는 run-parts 또는 Anacron을 통해 실행될 수 있습니다. 파일이 디렉터리에 존재한다고 해서 무조건 실행되는 것은 아닙니다.

1. run-parts 대상 파일 확인

실제로 실행 대상으로 인식되는 파일을 확인합니다.

run-parts --test /etc/cron.hourly
run-parts --test /etc/cron.daily

작성한 파일이 출력되지 않으면 파일명과 권한을 확인합니다. 배포판의 run-parts 규칙에 따라 점이 포함된 backup.sh 같은 이름이 제외될 수 있으므로 backup 또는 backup_daily처럼 문자, 숫자, 밑줄과 하이픈 중심의 파일명을 사용하는 것이 안전합니다.

ls -la /etc/cron.daily
file /etc/cron.daily/backup_daily
chmod 750 /etc/cron.daily/backup_daily

2. Anacron 실행 시각 확인

CentOS 7의 daily, weekly, monthly 작업은 cronie-anacron 구성에 따라 정확히 자정에 실행되지 않을 수 있습니다. START_HOURS_RANGE와 RANDOM_DELAY 설정 때문에 지정된 시간 범위 안에서 지연되어 실행될 수 있습니다.

rpm -q cronie-anacron
sed -n '1,200p' /etc/anacrontab
ls -l /var/spool/anacron

서버가 예약 시각에 꺼져 있어도 다음 부팅 후 실행되어야 하는 일일·주간 작업이라면 표준 사용자 crontab보다 Anacron 구성이 목적에 더 적합할 수 있습니다. 반대로 분 단위 또는 정확한 시각 실행이 필요한 작업에는 일반 Cron을 사용합니다.

3. 주기 디렉터리 스크립트 수동 실행

스크립트 자체 오류를 확인하려면 대상 디렉터리를 수동 실행할 수 있습니다. 운영 작업이 한꺼번에 실행될 수 있으므로 서버 부하와 작업 영향을 먼저 확인하십시오.

/bin/bash -x /etc/cron.daily/backup_daily

서버 시간·디스크·중복 실행 확인

1. 시간대와 CRON_TZ 확인

서버의 시스템 시간대와 crontab 안의 CRON_TZ 설정이 다르면 예상한 현지 시각과 실제 실행 시각이 달라질 수 있습니다.

timedatectl status
crontab -l | grep -E '^[[:space:]]*CRON_TZ='

시간대를 변경한 직후에는 기존 예상 시각이 아닌 변경된 시간대를 기준으로 다음 실행을 확인합니다. 갑작스러운 큰 시간 변경은 예약 동작에 영향을 줄 수 있으므로 시간 동기화 상태도 점검하십시오.

2. 디스크 용량과 inode 확인

디스크 또는 inode가 모두 소진되면 Cron이 임시 파일, 로그, 잠금 파일이나 결과 파일을 만들지 못할 수 있습니다.

df -h
df -i
ls -ld /tmp

/tmp의 일반적인 권한에는 sticky bit가 포함되어 drwxrwxrwt 형태로 표시됩니다. 권한을 변경하기 전에는 서버 정책과 현재 값을 확인하십시오.

3. 이전 작업이 끝나지 않았는지 확인

작업이 실행되지 않는 것이 아니라 이전 인스턴스가 장시간 실행 중이거나 자체 잠금 파일 때문에 다음 실행을 건너뛰는 경우가 있습니다.

pgrep -af 'my-job.sh'
ps -eo pid,ppid,user,lstart,etime,cmd | grep '[m]y-job.sh'

중복 실행을 방지해야 한다면 flock을 사용할 수 있습니다. 잠금 파일 경로는 실행 사용자가 쓸 수 있어야 합니다.

*/5 * * * * /usr/bin/flock -n /home/admin_user/my-job.lock /usr/local/bin/my-job.sh >> /home/admin_user/my-job.log 2>&1

이미 flock을 사용 중인데 작업이 전혀 실행되지 않는다면 오래된 잠금 파일 자체보다는 실제로 잠금을 잡고 있는 프로세스와 명령 종료 여부를 먼저 확인하십시오. flock 잠금은 일반적으로 프로세스가 종료되면 해제됩니다.

최소 테스트 작업으로 Cron 정상 여부 확인

복잡한 애플리케이션 작업을 계속 수정하기 전에 단순한 명령으로 Cron 서비스와 해당 사용자 crontab이 정상인지 분리하여 확인합니다.

1. 기존 crontab 백업

crontab -u admin_user -l > /root/admin_user.crontab.backup

해당 사용자에게 아직 crontab이 없으면 명령이 오류를 출력할 수 있습니다. 이 경우 기존 작업이 없다는 의미이므로 새 crontab을 생성하면 됩니다.

2. 1분 주기 테스트 작업 등록

다음 명령으로 admin_user의 crontab을 편집합니다.

crontab -u admin_user -e

편집기에 다음 한 줄을 추가합니다.

* * * * * /usr/bin/date '+\%F \%T cron-ok' >> /home/admin_user/cron-test.log 2>&1

3. 실행 결과와 Cron 로그 확인

1~2분 뒤 결과 파일과 Cron 로그를 확인합니다.

tail -n 10 /home/admin_user/cron-test.log
tail -n 50 /var/log/cron

테스트 로그에 매분 새로운 시각이 추가되면 crond와 해당 사용자 crontab은 정상입니다. 이 경우 원래 작업의 명령어, 환경 변수, 파일 권한, 외부 서비스 연결 또는 애플리케이션 오류에 집중합니다.

테스트 작업도 실행되지 않으면 서비스 상태, 사용자 접근 제한, crontab 파일 권한, SELinux와 시스템 로그를 다시 확인합니다.

4. 테스트 작업 제거

검증이 끝나면 crontab -u admin_user -e에서 테스트 한 줄을 삭제하고 필요하지 않은 테스트 로그도 제거합니다.

rm -f /home/admin_user/cron-test.log

자주 발생하는 증상과 해결 방법

백업과 원상복구 방법

사용자 crontab 백업

crontab -u admin_user -l > /root/admin_user.crontab.backup

사용자 crontab 복원

백업 파일 내용을 확인한 뒤 다음 명령으로 복원합니다. 이 명령은 현재 사용자의 전체 crontab을 백업 파일 내용으로 교체합니다.

crontab -u admin_user /root/admin_user.crontab.backup

시스템 Cron 파일 복원

/etc/crontab 또는 /etc/cron.d/ 파일을 수정하기 전 cp -a로 백업했다면 원래 파일을 복원하고 소유자, 권한과 SELinux 컨텍스트를 다시 확인합니다.

cp -a /etc/cron.d/my-job.backup /etc/cron.d/my-job
chown root:root /etc/cron.d/my-job
chmod 644 /etc/cron.d/my-job
restorecon -v /etc/cron.d/my-job

일반적인 crontab 변경은 Cron 데몬이 자동으로 감지하므로 매번 crond를 재시작할 필요는 없습니다. 다만 서비스 장애를 복구했거나 비정상 상태가 지속될 때는 로그를 확인한 뒤 재시작할 수 있습니다.

systemctl restart crond
systemctl status crond --no-pager -l

관련 지구 IDC 기술자료

• yum-cron을 이용한 자동 업데이트 — CentOS 7에서 일일 Cron 작업으로 자동 업데이트를 수행하는 기존 기술자료입니다.
• 지구 IDC 기술자료 전체 보기 — Linux 서버 운영과 장애 해결 관련 문서를 확인할 수 있습니다.

공식 참고자료

자주 묻는 질문

crontab을 수정한 뒤 crond를 재시작해야 하나요?

일반적으로 crontab -e로 저장한 작업과 /etc/crontab, /etc/cron.d/의 일반 파일 변경은 Cron이 감지하므로 매번 재시작할 필요가 없습니다. 다만 심볼릭 링크 대상만 변경했거나 데몬 자체가 비정상 상태라면 로그를 확인한 뒤 재시작이 필요할 수 있습니다.

sudo crontab -e와 crontab -e는 같은 작업인가요?

같지 않습니다. 일반 사용자가 실행한 crontab -e는 해당 사용자의 crontab을 편집하며, sudo crontab -e는 root의 crontab을 편집합니다. 작업을 어느 사용자 권한으로 실행해야 하는지 확인한 뒤 올바른 crontab을 편집해야 합니다.

/var/log/cron에 실행 기록이 있으면 작업은 성공한 것인가요?

아닙니다. 실행 기록은 Cron이 명령을 시작했다는 뜻이며, 명령의 성공 종료까지 보장하지 않습니다. 명령 뒤에 >> 작업로그 2>&1을 추가하고 종료 코드와 애플리케이션 로그를 함께 확인해야 합니다.

서버가 꺼져 있던 시간의 Cron 작업은 부팅 후 실행되나요?

일반 Cron 작업은 예약 시각에 서버가 실행 중이어야 하며 놓친 작업을 자동으로 소급 실행하지 않습니다. 일일·주간·월간 작업처럼 부팅 후 지연 실행이 필요한 경우에는 Anacron을 검토하십시오.

Cron에서 스크립트가 실행되지만 이메일 오류가 표시됩니다. 작업도 실패한 것인가요?

Cron은 기본적으로 작업 출력을 메일로 전달하려고 할 수 있습니다. 로컬 메일 전송 프로그램이 없으면 메일 관련 메시지가 나타날 수 있지만 작업 실행 자체와는 별개일 수 있습니다. 실제 작업 결과와 종료 상태를 파일 로그로 확인하고, 메일이 필요 없다면 crontab에서 MAILTO=""를 설정하거나 출력을 명시적으로 리디렉션하십시오.