crontab no Linux: sintaxe, regras PATH e verificação de logs

O comando crontab agenda tarefas periódicas em segundo plano em sistemas Linux através do daemon cron. Automatizar tarefas de forma fiável exige editar as tabelas de utilizador com crontab -e, definir cinco campos temporais e fornecer caminhos absolutos para os binários de modo a evitar falhas de execução provocadas pelo ambiente de shell predefinido e simplificado do cron.

A sintaxe de cinco campos de tempo em crontab -e

A tabela do cron analisa diretivas através de cinco parâmetros temporais seguidos pela linha de comandos executada pelo sistema operativo. A sintaxe exata lê-se sequencialmente da esquerda para a direita: minuto (0-59), hora (0-23), dia do mês (1-31), mês (1-12) e dia da semana (0-7, onde tanto 0 como 7 indicam domingo).

Para editar diretivas do cron para a conta de sistema ativa, execute a ferramenta de configuração interativa padrão:

crontab -e

Neste ficheiro de configuração, os asteriscos funcionam como caracteres universais para cada unidade de tempo, as vírgulas delimitam valores discretos, os hífenes especificam intervalos inclusivos e as barras definem intervalos de passos. Ao gerir estas configurações a partir de dispositivos móveis, ferramentas como o teclado especializado no termi1 para iOS e Android disponibilizam teclas ausentes como Esc, Ctrl, setas e Tab, simplificando edições no nano ou no Vim.

# Run database backups from Monday through Friday at 03:30
30 3 * * 1-5 /usr/local/bin/backup-cleanup.sh

# Run an external health check request every 15 minutes
*/15 * * * * /usr/bin/curl -fsS https://example.com/healthcheck

Resolver o ambiente PATH reduzido no crontab

O daemon cron nunca carrega ficheiros de ambiente interativos como ~/.bashrc, ~/.zshrc ou /etc/profile. Em instalações Linux padrão, a variável PATH predefinida no cron restringe-se estritamente a /usr/bin:/bin, originando falhas silenciosas sempre que os scripts referenciam binários localizados em /usr/local/bin, diretórios de utilizador ou ambientes de execução de aplicações.

Os administradores de sistemas utilizam três métodos para resolver discrepâncias de ambiente no crontab:

1. Utilizar caminhos absolutos para todos os utilitários de sistema, chamando /usr/local/bin/node ou /usr/bin/python3 em vez de nomes de comandos simples.
2. Definir a variável PATH no início do ficheiro de configuração do crontab antes de declarar tarefas.
3. Especificar a shell de execução explicitamente com SHELL=/bin/bash para evitar discrepâncias de dialeto com /bin/sh.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * backup-database --all

Redirecionar stdout e stderr para capturar o output do cron

O daemon cron tenta reencaminhar qualquer output gerado pelos processos agendados para o utilizador local através do agente de transporte de correio (MTA) local. Se a máquina remota não possuir um agente de correio funcional como o Postfix, todos os registos de execução e mensagens de erro críticas são descartados silenciosamente.

Para inspecionar os resultados das tarefas e diagnosticar problemas, é necessário redirecionar o standard output (descritor de ficheiro 1) e o standard error (descritor de ficheiro 2) para um ficheiro de registo de destino explícito no sistema de ficheiros:

0 4 * * * /usr/local/bin/sync-storage.sh >> /var/log/sync-storage.log 2>&1

O operador de redirecionamento >> anexa o texto de execução sem truncar entradas de registo anteriores, enquanto a expressão 2>&1 junta o stderr ao stdout. Ao resolver problemas em servidores a partir de um cliente móvel, pode inspecionar ou transferir estes ficheiros de registo de destino diretamente com um navegador SFTP integrado sem fechar a sessão de terminal.

Verificar a execução de tarefas com journalctl -u cron

O systemd regista a data/hora e o estado de execução de cada invocação do cron no diário central do sistema. A unidade de serviço chama-se cron em distribuições Debian e Ubuntu, ao passo que os sistemas RHEL e Fedora a registam sob o nome crond.

Para confirmar se o serviço de agendamento disparou a tarefa no intervalo esperado, consulte o diário unificado através do systemd:

# On Debian, Ubuntu, and derivatives
journalctl -u cron -n 50 --no-pager

# On RHEL, Rocky Linux, and Fedora
journalctl -u crond -n 50 --no-pager

Para acompanhar eventos de execução em direto durante fases de teste agendadas, execute o seguidor do journal:

journalctl -u cron -f

Ao rever registos em direto através de ligações móveis instáveis, a utilização do Mosh garante que a ligação do terminal se mantém responsiva durante transições entre Wi-Fi e dados móveis sem perder a sessão interativa.

Comparação da gestão de crontab: terminal móvel versus desktop

Gerir a automação de servidores em diferentes dispositivos clientes apresenta diferenças operacionais distintas:

Se os sistemas de destino não tiverem endpoints públicos acessíveis ou portas abertas, os administradores podem encaminhar o tráfego com segurança através de redes mesh sobrepostas como o Prialo para aceder à infraestrutura privada de forma segura.

Perguntas frequentes

Porque é que uma tarefa do crontab falha quando o mesmo comando funciona num terminal interativo?

O crontab executa comandos num ambiente minimalista que não herda as variáveis de perfil da shell. Se um script depender de caminhos personalizados, variáveis de ambiente ou binários fora das pastas predefinidas do sistema, falhará a menos que especifique caminhos absolutos ou declare explicitamente o PATH no cabeçalho do crontab.

Como inspecionar as tarefas cron do utilizador atual sem abrir um editor?

O comando crontab -l imprime o conteúdo do crontab do utilizador atual diretamente para o standard output sem criar bloqueios nem modificar ficheiros. Para apresentar tarefas agendadas pertencentes a outra conta de utilizador específica, execute crontab -u username -l recorrendo a privilégios de root.

Qual é a finalidade do identificador especial @reboot no crontab?

O identificador @reboot substitui os cinco campos temporais padrão numa entrada de crontab. Esta diretiva instrui o serviço cron a iniciar o script ou binário designado exatamente uma única vez, imediatamente após o servidor concluir a sequência de arranque do respetivo sistema operativo.

Onde se encontram as mensagens de registo do cron se o servidor não utilizar systemd?

Em sistemas Linux que utilizam daemons syslog clássicos sem o journald do systemd ativo, os avisos de execução do cron residem em /var/log/syslog nos sistemas Debian e Ubuntu, ou em /var/log/cron nas distribuições pertencentes à família Red Hat.