[LINUX] 크론탭이 갑자기 실행되지 않았을 경우, 오류 로그 확인과 해결방법

증상

매시간 정상적으로 돌던 크론탭이 어떤 시점을 이후로 실행되지 않았던 걸 발견했다.

스크립트는 수정한 적이 없고 크론탭으로 설정해둔 로그에는 오류도 없었다. 

 

로그 확인

/usr/sbin/crond -n

 

로그를 확인해보니 다음과 같은 메시지가 나왔다.

pam_unix(crond:account): expired password for user tomcat (password aged)
(tomcat) PAM ERROR (Authentication token is no longer valid; new one required)
(tomcat) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

 

첫 줄에 원인이 써져있었다.

계정의 비밀번호가 aging(사용 기간 만료) 정책에 의해 만료되었다는 뜻.

실제로 내가 그 전에 계정 패스워드 정책을 변경했었다.

리눅스 계정의 비밀번호 최대 사용 기간(예: chage로 설정된 PASS_MAX_DAYS) 정책에 걸려 자동으로 만료 처리된 것이었다.

 

그 아래 두 줄은 이 만료 상태가 실제 인증 단계에서 어떻게 반영되는지를 보여줬다. PAM 모듈이 계정 상태를 확인(account 단계)하는 과정에서 비밀번호 만료를 감지하고 PAM ERROR를 반환했고, 결국 crond는 해당 계정으로 인증을 완료하지 못해 FAILED to authorize user with PAM으로 작업 실행 자체를 포기했다. crond는 이 스크립트를 애초에 tomcat 계정 권한으로 실행하도록 설정되어 있었기 때문에, 정책 변경의 영향을 그대로 받은 것이었다.

 

원인

정리하면 흐름은 이랬다.

1. 사용자 정책 변경으로 비밀번호 재설정이 필요한 상태가 됨
2. 기존 로그인 세션은 유지되고 있어 사용자 입장에서는 변화를 인지하지 못함
3. crond는 매 실행마다 PAM을 통해 별도로 인증을 시도함
4. 비밀번호 만료가 감지되어 PAM 인증이 거부됨
5. 크론 작업이 조용히 실행되지 않음

비밀번호를 재설정한 이후로는 크론탭이 다시 정상적으로 도는 것을 확인했다. 

 

배운 점

크론탭은 실제 인증 토큰 상태를 그대로 반영한다는 점을 알게 됐다.

비밀번호 정책 변경이나 만료 주기가 있는 환경에서는

크론탭으로 돌아가는 배치 작업들이 이런 식으로 조용히 멈출 수 있다는 걸 알 수 있었다. 

정책 변경 할 때는 조심해야겠다.