ownCloud Cron 작업이 실행되지 않는 문제 해결: 안정적인 systemd 타이머 설정하기

ownCloud 관리자 페이지를 열었을 때 백그라운드 작업이 최근에 실행되지 않았거나, 정리, 활동, 외부 저장소 및 기타 대기 중인 작업이 지연되는 것을 발견할 수 있습니다. 흔히 cron.phpcrontab 항목을 수정하거나 추가하는 방식으로 문제를 해결하려고 하지만, 현재 ownCloud 서버 문서에서는 이러한 방법이 최선의 시작점이 아니라고 안내하고 있습니다. ownCloud는 Cron 백그라운드 모드와 해당 occ system:cron명령어를 사용할 것을 권장합니다. Linux 호스트에서는 기존 crontab 대신 systemd 타이머를 사용하여 스케줄링 계층을 제공할 수 있습니다.

이 가이드는 ownCloud가 `/.g.d`와 같은 경로에 있는 패키지 또는 베어메탈 방식 설치를 기준으로 작성되었습니다 /var/www/owncloud. ownCloud의 공식 Docker 이미지를 사용하는 경우 호스트 타이머를 생성하기 전에 작업을 중단하십시오. ownCloud 문서에 따르면 해당 이미지는 `/.g.d` 및 `/.g.d`와 같은 변수를 통해 제어되는 cron을 내부적으로 구성합니다 OWNCLOUD_CROND_ENABLED. ownCloud 백그라운드 작업 관련OWNCLOUD_CROND_SCHEDULE 최신 문서를 참조하십시오 .

검증된 항목, 서버에 따라 달라지는 항목, 그리고 추가 확인이 필요한 항목은 무엇인가요?

• 확인됨: ownCloud는 안정적인 백그라운드 실행을 위해 AJAX보다 Cron을 권장하며, occ system:cron대기 중인 백그라운드 작업을 실행하는 명령어로 Cron을 문서에 명시하고 있습니다.
• 설치 환경에 따라 다릅니다. ownCloud 디렉터리, PHP 바이너리, 웹 서버 계정, PHP 환경, 그리고 패키지 설치, 컨테이너, 어플라이언스 또는 사용자 지정 배포 여부에 따라 달라집니다.
• 일반적인 가이드로는 알 수 없는 문제: 현재 작업이 실패한 이유. 스케줄러 문제일 수도 있지만, 권한 문제, 잘못된 경로, PHP CLI 구성 오류, 데이터베이스 연결 문제, 파일 잠금 문제 또는 애플리케이션 수준의 백그라운드 작업 실패 등 다양한 원인이 있을 수 있습니다.

조치: 타이머에 사용할 계정과 동일한 계정에서 ownCloud 명령어가 수동으로 정상적으로 작동할 때까지 타이머를 생성하지 마십시오.

1단계: Cron 모드를 확인하고 ownCloud를 수동으로 테스트합니다.

일반적인 Apache/Debian 스타일 설치에서 웹 사용자는 `<web user>`입니다 www-data. 환경에 따라 사용자 이름과 경로를 모두 변경하십시오.

sudo -u www-data /var/www/owncloud/occ background:cron
sudo -u www-data /var/www/owncloud/occ system:cron

첫 번째 명령어는 ownCloud의 Cron 백그라운드 작업 모드를 선택합니다. 두 번째 명령어는 대기 중인 백그라운드 작업을 실제로 실행합니다. ownCloud의 occ 명령어 설명서에 따르면 이 명령어는 system:cron예약된 실행을 위한 것이며, 비대화형 스케줄러에서는 진행률 출력을 활성화해서는 안 됩니다.

흔히 오해하는 부분: ownCloud의 "크론 모드"는 반드시 ownCloud 데몬을 사용해야 한다는 의미가 아닙니다 cron. ownCloud는 외부 스케줄러가 백그라운드 작업 실행기를 호출하도록 기대한다는 뜻입니다. systemd 타이머가 그 스케줄러 역할을 할 수 있습니다.

조치: 수동 명령이 실패하면 먼저 해당 오류를 수정하십시오. 타이머는 예약된 시간에 동일한 오류가 반복될 뿐입니다.

2단계: 올바른 PHP 및 ownCloud 경로를 찾습니다.

일부 설치 환경에서는 occ실행 파일이 직접 생성되지만, PHP CLI 바이너리를 통해 실행될 때 더 예측 가능한 방식으로 작동합니다. 두 가지 모두 확인하십시오.

command -v php
readlink -f /var/www/owncloud/occ
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ system:cron

ownCloud의 문서에는 예약된 작업이 PHP를 찾아야 한다는 점이 명시적으로 경고되어 있으며, 따라서 cron 예제에 전체 경로가 나와 있습니다. 이는 systemd 환경에서도 마찬가지로 중요한데, 서비스가 사용자의 대화형 셸 환경이 아닌 제어된 환경에서 실행되기 때문입니다.

조치:/usr/bin/php 나머지 예제에서 , /var/www/owncloud, 및 를 www-data호스트에서 작동하는 값으로 바꾸십시오 .

3단계: 일회성 systemd 서비스 생성

만들다 /etc/systemd/system/owncloud-cron.service:

[Unit]
Description=Run ownCloud background jobs
After=network.target

[Service]
Type=oneshot
User=www-data
Group=www-data
WorkingDirectory=/var/www/owncloud
ExecStart=/usr/bin/php -f /var/www/owncloud/occ system:cron

[Install]일반적으로 타이머가 서비스를 활성화하므로 서비스에 대한 섹션 은 필요하지 않습니다 . Type=oneshot하지만 서비스를 별도의 섹션으로 유지하면 서비스의 수명 주기를 쉽게 파악할 수 있습니다. 즉, 서비스가 시작되어 명령을 한 번 실행한 후 종료되고 다시 비활성화됩니다.

흔히 오해하는 점: 비활성화된 원샷 서비스가 자동으로 종료되는 것은 아닙니다. 원샷 서비스는 정상적으로 실행된 후 RemainAfterExit=yes비활성화됩니다.

조치: 서비스가 계속 "실행 중"일 것으로 기대하지 말고, 종료 코드와 로그를 통해 성공 여부를 판단하십시오.

4단계: systemd 타이머 생성

만들다 /etc/systemd/system/owncloud-cron.timer:

[Unit]
Description=Run ownCloud background jobs every 15 minutes

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=owncloud-cron.service

[Install]
WantedBy=timers.target

ownCloud의 호스트 cron 문서에서는 15분 간격의 스케줄을 권장합니다. 위의 타이머는 해당 주기를 따릅니다. systemd는 시스템이 다시 사용 가능해진 후 누락된 캘린더 활성화를 트리거할 수 있으므로 타이머 Persistent=true와 함께 사용하면 유용합니다 OnCalendar. 정확한 동작은 systemd 버전과 시스템이 다운되었던 시간에 따라 달라집니다.

조치: 의도적으로 다른 간격이 필요한 경우, 다른 서버에서 값을 복사하지 말고 직접 변경하십시오. 실행 빈도가 높으면 백그라운드 부하가 증가할 수 있고, 실행 빈도가 낮으면 대기 중인 작업이 지연될 수 있습니다.

5단계: systemd를 다시 로드하고 타이머를 활성화합니다.

sudo systemctl daemon-reload
sudo systemctl enable --now owncloud-cron.timer
sudo systemctl status owncloud-cron.timer

daemon-reloadsystemd가 유닛 파일을 다시 읽도록 합니다. enable --now이는 향후 부팅을 위한 타이머를 활성화하는 동시에 즉시 타이머를 시작합니다.

조치: 타이머가 활성화되어 있지 않은 경우, systemctl status owncloud-cron.timerownCloud 구성을 다시 변경하기 전에 점검하십시오.

6단계: 다음 및 이전 타이머 실행을 확인합니다.

systemctl list-timers owncloud-cron.timer
systemctl list-timers --all | grep owncloud-cron

list-timerssystemd가 다음 활성화를 예약했는지 확인하고 타이머가 마지막으로 실행된 시점을 확인하는 가장 빠른 방법입니다. 이를 통해 "타이머가 실행되지 않음"과 "타이머는 실행되었지만 ownCloud 서비스 내부에서 오류가 발생함"을 구분할 수 있습니다.

조치: NEXT가 없거나 타이머가 목록에 없는 경우 타이머 파일 이름, [Install]섹션 및 장치가 활성화되었는지 여부를 다시 확인하십시오.

7단계: 타이머뿐만 아니라 서비스 기록도 확인하십시오.

systemd는 사용자가 의도적으로 다른 곳으로 리디렉션하지 않는 한 서비스 출력을 저널에 기록합니다. 공식 journalctl 설명서에는 systemd 유닛별로 저널 항목을 필터링하는 방법이 설명되어 있습니다.

sudo journalctl -u owncloud-cron.service --since today
sudo journalctl -u owncloud-cron.service -n 100 --no-pager

흔히 오해하는 부분: "타이머가 활성화되어 있으니 ownCloud cron이 작동하는 거야." 활성화된 타이머는 스케줄러가 실행 대기 중이라는 것만 증명할 뿐입니다. 서비스가 성공적으로 호출되어야만 제대로 작동합니다.

조치: PHP 오류, 권한 거부 메시지, 파일 누락, 데이터베이스 오류 또는 0이 아닌 종료 상태를 찾으십시오. 타이머를 반복적으로 재시작하기보다는 처음 발생하는 구체적인 오류를 수정하십시오.

8단계: 필요에 따라 한 번 실행을 트리거하고 ownCloud를 확인합니다.

기말고사를 위해 15분을 기다릴 필요가 없습니다.

sudo systemctl start owncloud-cron.service
sudo systemctl status owncloud-cron.service
sudo -u www-data /usr/bin/php -f /var/www/owncloud/occ status

일회성 실행이 systemctl status성공적으로 완료되면 서비스가 비활성 상태임을 보고하는 동시에 해당 상태를 표시할 수 있습니다 status=0/SUCCESS. 중요한 결과는 명령이 성공적으로 완료되었다는 것입니다.

조치: 수동 서비스 테스트가 성공하면 예약된 타이머가 최소 한 번 작동할 때까지 기다린 후 수동 개입 없이 새 저널 항목이 나타나는지 확인하십시오.

그래도 실행되지 않으면 레이어별로 문제를 해결해 보세요.

cron.php 및 이전 가이드에 대한 참고 사항

이전 ownCloud 지침에서는 종종 cron.php직접 호출하는 경우가 있었습니다. 최신 ownCloud 문서에서는 를 권장하며 occ system:cron, ownCloud 릴리스 노트에서는 이전의 직접 호출 방식에서 로 변경된 내용을 설명합니다 cron.php. ownCloud 서버 릴리스 노트를 참조하십시오 .

조치: 기존에 실행 중인 crontab 또는 systemd 유닛을 물려받은 경우 cron.php, 해당 유닛을 유지하기 전에 설치된 ownCloud 릴리스의 설명서와 비교하십시오.

최종 확인 체크리스트

• ownCloud는 Cron 백그라운드 작업을 위해 구성되어 있습니다.
• occ system:cron해당 웹 서버 계정으로 실행하면 정확한 명령이 성공적으로 실행됩니다.
• owncloud-cron.timer활성화되어 있습니다 active (waiting).
• systemctl list-timers충분한 시간이 지난 후 다음 활성화와 이전 활성화를 모두 보여줍니다.
• journalctl -u owncloud-cron.service예약된 실행이 성공적으로 완료되었음을 보여줍니다.
• 이 설정은 공식 ownCloud Docker 이미지 또는 다른 스케줄러에서 이미 제공하는 cron을 중복해서 생성하지 않습니다.

이러한 검사가 모두 통과되면 "타이머가 존재한다"는 것 이상의 것을 확인한 것입니다. systemd가 작업을 예약하고, 올바른 계정으로 ownCloud를 호출하고, 실제 백그라운드 작업 실행기를 성공적으로 완료한다는 것을 입증한 것입니다.