Corrigir problema com tarefa cron do ownCloud que não está sendo executada: configure um temporizador systemd confiável.

Ao abrir a página de administração do ownCloud, você percebe que tarefas em segundo plano não foram executadas recentemente, ou que tarefas de limpeza, atividade, armazenamento externo e outras tarefas enfileiradas parecem atrasadas. Uma reação comum é editar cron.phpou adicionar outra entrada no crontab. Na documentação atual do ownCloud Server, essa não é a melhor abordagem: o ownCloud recomenda o modo de execução em segundo plano do Cron e o occ system:croncomando apropriado. Um timer do systemd pode fornecer a camada de agendamento em vez do crontab tradicional em um host Linux.

Este guia se concentra em uma instalação do tipo pacote ou bare-metal, onde o ownCloud reside em um caminho como `/ usr /var/www/owncloud/local/bin`. Se você estiver usando a imagem Docker oficial do ownCloud, pare antes de criar um temporizador de host: a documentação do ownCloud indica que a imagem já configura o cron internamente, controlado por variáveis ​​como `cron_id` OWNCLOUD_CROND_ENABLEDe `cron_id` OWNCLOUD_CROND_SCHEDULE. Consulte a documentação atual de tarefas em segundo plano do ownCloud .

O que já foi verificado, o que depende do seu servidor e o que ainda precisa ser verificado.

• Verificado: o ownCloud recomenda o Cron em vez do AJAX para execução confiável em segundo plano e o documenta occ system:croncomo o comando para executar tarefas em segundo plano enfileiradas.
• Depende da sua instalação: o diretório ownCloud, o binário PHP, a conta do servidor web, o ambiente PHP e se você está executando uma instalação de pacote, contêiner, dispositivo ou implantação personalizada.
• Não é possível saber, a partir de um guia genérico, por que sua tarefa atual falhou. Pode ser um problema de agendamento, mas também pode ser uma questão de permissões, um caminho incorreto, uma configuração diferente do PHP CLI, conectividade com o banco de dados, bloqueio de arquivo ou uma falha em uma tarefa em segundo plano no nível do aplicativo.

Ação: não crie um temporizador até que o mesmo comando do ownCloud funcione manualmente na mesma conta que o temporizador utilizará.

Passo 1: Confirme o modo Cron e teste o ownCloud manualmente.

Para uma instalação típica no estilo Apache/Debian, o usuário web é www-data. Substitua o usuário e o caminho se o seu ambiente for diferente.

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

O primeiro comando seleciona o modo de execução em segundo plano Cron do ownCloud. O segundo executa, de fato, as tarefas em segundo plano enfileiradas. A documentação do comando `occ` do ownCloud afirma que system:cronele se destina à execução agendada e que a saída de progresso não deve ser habilitada em um agendador não interativo.

Equívoco comum: o "modo cron" no ownCloud não significa que você precise usar o crondaemon especificamente. Significa que o ownCloud espera que um agendador externo invoque seu executor de tarefas em segundo plano. Um temporizador do systemd pode ser esse agendador.

Ação: se o comando manual falhar, corrija esse erro primeiro. Um temporizador só repetirá a mesma falha em um horário programado.

Etapa 2: Encontre os caminhos corretos do PHP e do ownCloud

Algumas instalações geram occo executável diretamente; outras são mais previsíveis quando invocadas com o binário da linha de comando do PHP. Confirme ambas:

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

A documentação do ownCloud alerta explicitamente que as tarefas agendadas precisam encontrar o PHP e, portanto, mostra os caminhos completos nos exemplos de cron. Isso é igualmente importante no systemd, pois os serviços recebem um ambiente controlado em vez do seu ambiente de shell interativo.

Ação: substitua /usr/bin/php, /var/www/owncloud, e www-datanos exemplos restantes pelos valores que funcionaram no seu host.

Passo 3: Crie um serviço systemd de execução única

Criar /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

Normalmente, você não precisa de uma [Install]seção para o serviço, pois o temporizador o ativa. Manter o serviço como está Type=oneshottambém facilita a interpretação de seu ciclo de vida: ele inicia, executa o comando uma vez, encerra e volta a ficar inativo.

Equívoco comum: um serviço de execução única inativo não é automaticamente interrompido. Após uma execução bem-sucedida, um serviço de execução única RemainAfterExit=yesnormalmente se torna inativo.

Ação: avalie o sucesso pelo código de saída e pelo registro de atividades, e não esperando que este serviço permaneça "em funcionamento".

Passo 4: Criar o temporizador systemd

Criar /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

A documentação do host-cron do ownCloud recomenda um agendamento de 15 minutos. O temporizador acima segue essa cadência. Persistent=trueÉ útil usar um OnCalendartemporizador porque o systemd pode acionar uma ativação de calendário perdida depois que a máquina voltar a ficar disponível. O comportamento exato ainda depende da versão do systemd e de quanto tempo a máquina ficou inativa.

Ação: se você precisar intencionalmente de um intervalo diferente, altere-o deliberadamente em vez de copiar um valor de outro servidor. Execuções mais frequentes podem aumentar a carga em segundo plano; execuções menos frequentes podem atrasar o trabalho em fila.

Passo 5: Recarregue o systemd e ative o temporizador.

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

daemon-reloadFaz com que o systemd releia os arquivos de unidade. enable --nowIsso habilita o temporizador para inicializações futuras e o inicia imediatamente.

Ação: se o temporizador não estiver ativo, verifique systemctl status owncloud-cron.timerantes de alterar novamente a configuração do ownCloud.

Etapa 6: Verifique se os temporizadores anterior e seguinte foram executados.

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

list-timersÉ a maneira mais rápida de confirmar se o systemd agendou uma próxima ativação e de ver quando o temporizador foi acionado pela última vez. Isso distingue "o temporizador nunca foi executado" de "o temporizador foi executado, mas o ownCloud falhou dentro do serviço".

Ação: se NEXT estiver ausente ou o temporizador não estiver listado, verifique novamente o nome do arquivo do temporizador, [Install]a seção e se a unidade foi ativada.

Passo 7: Verifique o registro de serviço, não apenas o temporizador.

O systemd registra a saída do serviço no diário, a menos que você a redirecione deliberadamente para outro local. A documentação oficial do journalctl descreve como filtrar entradas do diário por unidade do systemd.

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

Equívoco comum: "O temporizador está ativo, então o cron do ownCloud funciona." Um temporizador ativo apenas comprova que o agendador está aguardando para ser executado. Você ainda precisa de uma invocação de serviço bem-sucedida.

Ação: procure por erros de PHP, mensagens de permissão negada, arquivos ausentes, erros de banco de dados ou um código de saída diferente de zero. Corrija o primeiro erro concreto em vez de reiniciar o temporizador repetidamente.

Etapa 8: Execute uma operação sob demanda e verifique o ownCloud.

Você não precisa esperar 15 minutos para o teste final:

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

Após uma execução systemctl statusbem-sucedida em uma única tentativa, é possível relatar o serviço como inativo e, ao mesmo tempo status=0/SUCCESS, exibir o resultado importante: o comando foi concluído com êxito.

Ação: após o teste de serviço manual ser bem-sucedido, aguarde pelo menos uma ativação do temporizador agendado e confirme se uma nova entrada no diário aparece sem intervenção manual.

Se ainda não funcionar: solucione o problema camada por camada

Uma nota sobre o cron.php e guias antigos.

As instruções antigas do ownCloud geralmente invocavam o comando cron.phpdiretamente. A documentação atual do ownCloud recomenda o uso occ system:crondo comando `source`, e as notas de versão do ownCloud explicam a migração da antiga cron.phpabordagem direta. Consulte as notas de versão do servidor ownCloud .

Ação: se você herdou uma unidade crontab ou systemd antiga que executa cron.php, compare-a com a documentação da sua versão instalada do ownCloud antes de mantê-la.

Lista de verificação final

• O ownCloud está configurado para tarefas em segundo plano cron.
• O occ system:croncomando exato é executado com sucesso na conta do servidor web pretendida.
• owncloud-cron.timerestá habilitado e active (waiting).
• systemctl list-timersMostra tanto a ativação seguinte quanto a anterior após um período de tempo suficiente.
• journalctl -u owncloud-cron.serviceMostra execuções agendadas com sucesso.
• A configuração não duplica o cron já fornecido pela imagem Docker oficial do ownCloud ou por outro agendador.

Quando todas essas verificações forem aprovadas, você terá verificado mais do que apenas "a existência de um temporizador": você terá demonstrado que o systemd agenda a tarefa, invoca o ownCloud na conta correta e conclui com sucesso a execução da tarefa em segundo plano.