Systemd 타이머를 사용하여 ownCloud 백그라운드 작업을 안정적으로 실행하세요

ownCloud 관리자 페이지에 백그라운드 작업이 실행되고 있지 않다고 표시되면, 대기 중인 정리 작업이나 기타 예약된 작업이 사용자가 사이트를 방문할 때까지 지연될 수 있습니다. systemd로 관리되는 Linux 서버에서는 ownCloud 백그라운드 작업 모드를 Cron으로 구성하고 occ system:cron웹 서버 계정으로 실행되는 타이머를 사용하십시오. 현재 ownCloud 서버 설명서에서는 정기적인 백그라운드 작업을 위해 시스템 cron 사용을 권장하며, 특히 systemd 타이머를 명령 예약의 또 다른 방법으로 언급하고 있습니다.

이 가이드는 Linux 호스트에 직접 설치된 ownCloud Server Classic을 기준으로 작성되었습니다. 아키텍처가 다른 ownCloud Infinite Scale이나 cron이 이미 내부적으로 실행되는 공식 ownCloud Docker 이미지에는 적용되지 않습니다. Docker 이미지의 경우, 별도의 호스트 타이머를 생성하는 대신 이미지에 명시된 설정 방법을 따르십시오. 자세한 내용은 ownCloud 서버 백그라운드 작업 관련 문서를 참조하십시오 .

일정을 변경하기 전에 명령어를 확인하세요.

systemd 서비스 는 실행할 명령어를 정의하고, 타이머는 해당 서비스를 주기적으로 시작합니다. 먼저 ownCloud 설치 경로와 HTTP 서버 계정을 확인하십시오. 아래 예제에서는 Debian 및 Ubuntu에서 흔히 사용되는 `sudo`와 `requests` 계정을 사용합니다 /var/www/owncloud. 다른 Linux 배포판에서는 `sudo`, `requests` 또는 다른 계정을 www-data사용할 수 있습니다 .wwwrunapache

명령 오류와 예약 오류를 구분하려면 해당 계정으로 ownCloud 명령을 수동으로 실행하세요.

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

PHP 실행 파일과 경로를 occ서버에 맞게 변경하십시오. ownCloud는 system:cron백그라운드 작업에 를 사용하는 것을 권장합니다. 이전 가이드에서는 cron.php예약 실행에 대한 내용이 포함되어 있을 수 있습니다. 현재 실행 중인 명령은 성공 메시지를 출력하지 않고 완료될 수 있으므로, echo $?직후에 종료 상태를 확인하십시오. 0는 명령이 성공적으로 종료되었음을 의미합니다. 오류가 발생하면 경로, PHP CLI 설치, 권한, 데이터베이스 연결 또는 ownCloud 오류를 먼저 해결하십시오. 이 단계를 건너뛰면 타이머가 동일한 실패한 명령을 반복적으로 실행합니다.

ownCloud를 Cron 모드로 설정

ownCloud 관리자 설정에서 백그라운드 작업 또는 Cron 섹션을 열고 Cron을 선택합니다 . 설치 디렉터리에서 다음 명령어를 사용하여 스케줄러를 설정할 수도 있습니다.

cd /var/www/owncloud
sudo -E -u www-data php occ background:cron

이 명령은 Cron 모드를 선택하며, 예약된 명령은 그대로 유지됩니다 occ system:cron. ownCloud 설명서에 따르면 이 명령은 관리자 페이지에서 Cron을 선택하는 것과 동일합니다. AJAX는 페이지 방문에 따라 작동하므로 사용량이 적은 시간대에는 작업이 지연될 수 있기 때문에, 작업을 안정적으로 처리해야 하는 서버에는 Cron이 더 적합합니다. 소규모 개인 인스턴스의 경우 AJAX가 더 간편할 수 있지만, 예측 가능성이 떨어집니다.

systemd 서비스와 타이머를 생성합니다.

/etc/systemd/system/owncloudcron.service실제 HTTP 계정과 ownCloud 경로를 사용하여 생성하세요 .

[Unit]
Description=ownCloud background jobs

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

Type=oneshot이 명령은 systemd에 명령이 완료될 때까지 실행한 후 종료됨을 알려줍니다. 전체 PHP 경로를 제공하면 PATH시스템 서비스에서 사용할 수 있는 제한된 리소스에 의존하지 않게 됩니다. 작업 디렉터리는 ownCloud가 상대 경로를 해석하는 데 도움이 됩니다. 서비스 계정은 ownCloud 파일 및 데이터 액세스 권한의 소유자와 일치해야 합니다. 루트 권한으로 작업을 실행하지 마십시오.

다음으로 생성하세요 /etc/systemd/system/owncloudcron.timer:

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

[Timer]
OnBootSec=5min
OnUnitActiveSec=15min
Unit=owncloudcron.service

[Install]
WantedBy=timers.target

ownCloud 설명서에서는 표준 cron 예제에 15분 주기를 권장하며, systemd 타이머를 대체 스케줄러로 제시합니다. 이 타이머는 부팅 후 5분 뒤에 시작하여 서비스 활성화 후 15분마다 다시 실행되도록 예약합니다. 워크로드에 따라 다른 간격이 필요한 경우, OnUnitActiveSec각 실행에 필요한 시간을 고려하여 간격을 신중하게 변경하십시오. 동일한 명령에 대해 여러 개의 crontab 항목을 구성하지 마십시오. 중복된 스케줄러는 불필요한 실행을 유발하여 문제 해결을 어렵게 만들 수 있습니다.

systemd에게 유닛 정의를 다시 로드하도록 지시한 다음 타이머를 활성화하고 시작하십시오.

sudo systemctl daemon-reload
sudo systemctl enable --now owncloudcron.timer

daemon-reload유닛 파일을 생성하거나 편집한 후에는 타이머 활성화가 필요합니다. 타이머를 활성화하면 이후 부팅 시 자동으로 시작되며, --now현재 세션에서도 자동으로 시작됩니다. 서비스가 아닌 타이머 유닛 자체를 활성화해야 합니다.

실행이 건너뛰어지거나 실패한 이유를 찾아보세요

타이머가 활성화되어 있는지, 그리고 다음 실행 시점이 언제인지 확인하십시오.

systemctl is-enabled owncloudcron.timer
systemctl list-timers --all owncloudcron.timer
systemctl status owncloudcron.timer

활성화된 타이머는 타이머 목록에 다음 활성화 날짜와 함께 표시되어야 합니다. 표시되지 않으면 장치 파일 이름을 확인하고 systemd를 다시 로드한 다음 타이머를 다시 활성화하십시오. 타이머가 실행 중으로 표시되지만 ownCloud 작업이 여전히 지연되는 경우 서비스 및 해당 로그를 검사하십시오.

systemctl status owncloudcron.service
sudo journalctl -u owncloudcron.service --since today

잘못된 경로, 접근할 수 없는 데이터 디렉터리, 누락된 PHP 확장 프로그램 또는 데이터베이스 오류가 있는지 확인하십시오. 서비스 파일에서 정확한 명령을 수동으로 테스트하여 환경을 최대한 비슷하게 재현하십시오. 또한 Nextcloud 예제를 복사하여 사용하는 대신 www-dataownCloud 명령을 사용했는지 확인하십시오 .occ system:croncron.php

ownCloud가 작업을 처리하고 있는지 확인하십시오.

한두 번의 타이머 간격이 지난 후 서비스가 성공적으로 완료되었는지, 그리고 타이머가 이후 활성화 일정을 제대로 설정했는지 확인하십시오. 그런 다음 ownCloud 관리자 페이지에서 백그라운드 작업 상태를 확인합니다. 표시되는 마지막 실행 시간이 증가하고 오래된 Cron 경고가 사라져야 합니다. systemd에서 성공을 보고했지만 경고가 여전히 남아 있는 경우 ownCloud 애플리케이션 로그를 검사하고 웹 UI가 명령줄 설치에서 사용하는 것과 동일한 인스턴스 및 데이터베이스에 연결되어 있는지 확인하십시오.

공식 ownCloud 컨테이너의 경우, 컨테이너의 내부 스케줄러를 의도적으로 비활성화했고 ownCloud의 최신 컨테이너 문서에서 해당 구성을 지원하는 경우가 아니면 이러한 호스트 유닛을 설치하지 마십시오. 여기에 제시된 구성은 systemd 기반의 기존 ownCloud 환경을 위한 호스트 수준 솔루션입니다. 서비스 이름, 경로, PHP 버전 및 컨테이너 동작은 배포 환경에 따라 달라집니다.

댓글 남기기

occ 명령어를 사용하여 ownCloud 파일 버전을 안전하게 삭제하세요

occ 명령어를 사용하여 ownCloud 파일 버전을 안전하게 삭제하세요

계정 하나 또는 모든 사용자에 대해 저장된 모든 ownCloud Server Classic 파일 버전을 삭제하고, 전체 삭제와 보존 기간 만료를 구분할 수 있습니다.

ownCloud 모바일 연결이 거부되었나요? URL 및 연결 가능성을 확인하세요.

ownCloud 모바일 연결이 거부되었나요? URL 및 연결 가능성을 확인하세요.

ownCloud 모바일 연결 거부 문제를 추적하려면 서버 URL, 휴대폰 네트워크, HTTPS 엔드포인트 및 서버 로그를 올바른 순서대로 확인하십시오.

Systemd 타이머를 사용하여 ownCloud 백그라운드 작업을 안정적으로 실행하세요

온디맨드 작업 실행을 ownCloud에서 지원하는 occ system:cron 명령을 15분마다 실행하는 systemd 타이머로 대체합니다.

손상된 경로를 찾아 ownCloud WebDAV 동기화를 복원하세요

Apache, Nginx 또는 리버스 프록시를 통해 WebDAV 요청을 추적한 다음 인증된 PROPFIND 테스트를 사용하여 ownCloud 동기화가 제대로 작동하는지 확인하십시오.

Nextcloud가 자체적으로 접속할 수 있도록 공개 URL을 설정하세요.

Nextcloud에서 발생하는 발신 주소 누락 경고를 해결하려면 정규 URL을 설정하고 서버 자체에서 DNS, HTTPS 및 역방향 프록시 라우팅을 확인하십시오.

Ubuntu 24.04에서 Nextcloud Redis 캐싱 설정하기

Ubuntu 24.04에서 Nextcloud Redis 캐싱 설정하기

Nextcloud 캐싱 및 파일 잠금을 위해 로컬 Unix 소켓을 통해 APCu와 Redis를 구성하는 방법을 설명합니다. 최신 및 이전 Nextcloud 버전에 대한 단계별 지침이 포함되어 있습니다.

Systemd 타이머를 사용하여 Nextcloud Cron을 자동으로 실행하세요

Nextcloud의 cron 모드를 확인하고, systemd 서비스와 타이머를 복구하고, 백그라운드 작업이 시작 후 및 5분마다 실행되는지 확인하십시오.

Redis를 사용하여 Nextcloud의 파일 잠금 경고를 해결하세요

Nextcloud 파일 잠금 기능을 안정적으로 활성화하고, 적절한 Redis 또는 Valkey 백엔드를 선택한 다음, 동시 파일 변경 위험 없이 경고가 사라지는지 확인하십시오.

Nextcloud에서 A+ 보안 등급을 획득하기 위해 필요한 것

Nextcloud에서 A+ 보안 등급을 획득하기 위해 필요한 것

최신 업데이트, HTTPS 및 HSTS 지원, 정확한 리버스 프록시 신뢰 설정, 그리고 공용 서버 검사를 통해 Nextcloud 스캔에서 흔히 발견되는 문제들을 해결하세요.

Nextcloud 서버 측 암호화를 활성화하고 영향 분석을 통해 효과를 확인하세요.

기존 파일을 암호화하기 전에 필요한 스토리지에 맞게 Nextcloud SSE를 구성하고, 암호화 키를 보호하고, 전송 및 CPU 사용량에 미치는 영향을 측정하십시오.