cron에서 systemd 타이머로 전환되는 이유: 역사적 배경과 설계 철학 분석

·

리눅스의 주기적 실행은 1970년대 최적화된 cron의 상태 관리 및 의존성 문제로 인해 프로세스 관리와 로그, 재실행 제어 등을 통합하는 systemd timer로 전환되고 있다.

#sysemd#cron

AI 요약

핵심 인사이트

  • Cron은 1970년대(Unix V6~V7)의 제한된 환경(수MB 디스크, 수백KB 메모리)에 최적화된 경량 스케줄러였으나, 현대 서버 운영에 필수적인 실행 상태 관리, 로그 저장, 의존 관계 정의 기능을 제공하지 못해 운영의 비효율성을 초래했습니다.
  • Systemd는 리눅스 전체를 상태 관리하는 제어 기반으로 설계되었으며, timer 유닛은 단순한 스케줄링이 아닌 서비스 유닛을 실행하는 '트리거' 역할만 담당하여 책임 분리를 통해 통합적인 잡(Job) 관리를 가능하게 합니다.
  • Systemd timer는 스케줄링, 프로세스 관리, 로그, 종속성, 재실행 제어를 모두 통합하여 '시간을 알리는 것'에 그쳤던 cron과 달리 '잡을 관리'하는 현대적 표준으로 제시됩니다.

주요 디테일

  • Cron은 실행 이력 개념이 없어 성공 여부나 소요 시간을 OS 차원에서 추적하지 못하며, 로그를 표준으로 저장하지 않아 출력 선언, 로테이션, 실패 검출 등을 수동으로 처리해야 했습니다.
  • Cron의 가장 큰 문제 중 하나는 취약한 재부팅 대처 능력으로, 서버 정지 중에 실행 시각이 지나면 해당 작업은 영구적으로 손실되는 ‘작업 놓침’ 현상이 발생했습니다.
  • Systemd timer는 서비스 파일과 타이머 파일의 '2파일 1세트'로 구성되며, 타이머 파일에 Persistent=true 옵션을 설정할 경우 서버 정지 중 놓친 작업을 부팅 후 보완 실행(취소 방지) 해줍니다.
  • Systemd는 service, timer, socket, mount 등을 'unit'이라는 단위로 관리하며, timer는 service를 호출함으로써 종속 관계 정의(예: After=network-online.target) 및 종료 코드, 재실행 제어 등을 OS 차원에서 자연스럽게 처리합니다.

Share

이것도 읽어보세요

댓글

이 소식에 대한 의견을 자유롭게 남겨주세요.

댓글 (0)

불러오는 중...