Crontab 관련: index.php common.cron 과 /common/scripts/cron.php 의 차이

Rhymix 비동기 실행 방식

라이믹스는 기본적으로 index.php common.cron 형태를 통해 크론이 실행되도록 설계되어 있습니다.

/usr/bin/php /내경로/www/index.php common.cron

• index.php → 코어 부트스트랩을 거치면서 전체 환경을 로드

• common.cron → Rhymix에서 예약된 작업(비동기 큐, 세션/캐시 정리, 모듈 크론 등)을 실행

즉, 이것이 공식적으로 권장되는 표준 방식이에요.

/common/scripts/cron.php 실행

/usr/bin/php /내경로/www/common/scripts/cron.php

이 경로는 index.php를 거치지 않고 cron.php 단독 실행 스크립트를 호출하는 방식입니다.
이 스크립트는 원래 개발/테스트용 혹은 단순화된 환경에서 크론을 돌리기 위한 백도어처럼 존재하는데, 환경 초기화 절차가 index.php 방식보다 단순합니다.

• 장점: 큐 처리(addtask → xe_task_queue)가 빠르게 동작할 수 있음

• 단점: index.php 로딩 과정을 건너뛰므로 특정 모듈이나 트리거가 누락될 수 있음

왜 cron.php는 되고 index.php common.cron은 안 되었을까?

가능한 원인은 다음과 같아요.

1. 환경 차이

   • index.php common.cron은 모듈 트리거까지 모두 실행 → 특정 모듈에서 에러가 나면 queue insert까지 영향을 줄 수 있음.

   • 반면 cron.php는 단순화된 로직만 실행 → 그 에러를 우회했을 수 있음.

2. CLI 인자 전달 문제

   • index.php common.cron 방식에서 common.cron 인자가 제대로 전달되지 않으면 원하는 로직이 실행되지 않을 수 있음.

   • PHP CLI 버전 차이나 shebang 환경 문제로 발생할 수 있어요.

3. 퍼미션/경로 문제

   • queue.log 확인해보면, index.php 실행 시 특정 모듈에서 Warning이나 Fatal이 발생해 큐 추가가 막혔을 가능성 있음.

어떻게 쓰는 게 안전할까?

• 공식적이고 안정적인 방식은 index.php common.cron입니다.

• cron.php는 임시 대안으로 쓸 수 있지만, 장기적으로는 권장되지 않아요.

• 지금처럼 cron.php가 잘 되는 상황은 사실 underlying 에러를 가리고 있는 것일 가능성이 큽니다.

👉 따라서, queue.log를 확인해서 index.php common.cron 실행 시 무슨 에러가 났는지 추적하는 게 중요합니다.
(아마 특정 모듈의 트리거나 함수에서 오류가 나서 addtask 실행까지 방해했을 확률이 높습니다.)

정리

• index.php common.cron = 표준, 모든 기능/트리거 정상 실행

• cron.php = 단순 실행, 일부 문제를 회피할 수 있지만 비권장

• 지금은 cron.php가 잘 되는 게 아니라, index.php common.cron 실행 중간에 오류가 있어서 addtask가 막힌 것일 가능성이 큼 → 로그 확인이 필요

chatgpt 답변을 보니 이러면 안되는거구나 싶긴한데 /logs/queue.log에 로그내용이 없어서 원인을 모르겠네요. 로그 작성하도록 설정했는데..

common/scripts/cron.php를 직접 호출하는 것은 웹크론 방식입니다.

crontab에서는 이 파일을 직접 호출하면 안 됩니다.

만약 된다면 버그이니 차단하겠습니다.

다른 작업 도중 addTask로 추가한 작업을 백그라운드에서 실행하는 것이 일반적인데,

백그라운드 작업 도중 addTask를 하려고 하셨다는 뜻인가요?