[Dúvida] Agendando tarefas imediatas

Olá Jezebel.
Tem coisas que acontecem que é bom nem entendermos o porquê!
Este não é o caso... ^^)
A situação que você descreveu provavelmente está relacionada ao relógio do sistema e ao tempo mínimo necessário para o at agendar uma tarefa futura com sucesso.
Vamos detalhar os possíveis motivos pelos quais o at com + 3 minutes não exibiu nada no atq, enquanto com + 10 minutes funcionou corretamente:
O at só agenda comandos para o futuro.
Se, por algum motivo, a hora atual do sistema estava próxima de 23:33:00 no momento em que você executou:

echo "/home/jezebel/scripts-linux/monitoramento-logs.sh" | at now + 3 minutes

...mas o at interpretou que o tempo agendado estava no presente ou no passado (mesmo que por milissegundos), ele pode ter executado imediatamente ou descartado o job sem erro visível.
O comando atq exibe apenas os jobs pendentes.
Se o job já foi executado ou removido, ele não aparece.
Se o script monitoramento-logs.sh executa algo muito rápido (como apenas um echo ou logger), pode ser que:

• O job foi executado quase imediatamente após o agendamento.
• Quando você rodou atq, ele já havia sido concluído.
• Você não percebeu a execução porque ela foi silenciosa (sem saída visível ou logs).
  O que pode ter acontecido?
• Você rodou o comando com + 3 minutes quando já estava próximo de 23:30:00, por exemplo.
• O at interpretou o tempo como quase imediato.
• O job foi executado quase no mesmo instante ou muito pouco depois.
• Ao consultar atq, ele já tinha sido removido da fila.

Como testar corretamente?

1. Use date para confirmar a hora do sistema:

   date
   

2. Agende com um tempo um pouco maior (como 5 ou 10 minutos):

   echo "echo teste >> /tmp/saida.txt" | at now + 10 minutes
   

3. Confirme com atq que o job está na fila:

   atq
   

4. Verifique a execução depois do horário agendado.

Se você estiver testando como root ou em um sistema com permissões restritas, verifique também os arquivos:

• /etc/at.allow
• /etc/at.deny

Esses arquivos controlam quem pode usar o at.
Comente ai se a explicação lhe convenceu ou é algo do além!
Brincadeiras a parte continue explorando esse universo imenso que é Linux.
Bons estudos e se pintar uma duvida pode perguntar.
Obrigado.

Olá, Ronaldo!
Realizei o teste verificando a hora do sistema, e fez total sentido. Muito obrigada por detalhar tudo com tanta clareza.
Definitivamente não foi “coisa do além” .
Percebi que o arquivo .sh foi executado quase instantaneamente, enquanto o comando com o .txt respeitou o tempo configurado. Isso acontece porque o at interpreta de forma diferente comandos diretos e scripts.
Ao agendar um .sh, o sistema tenta executá-lo imediatamente se o tempo estiver muito próximo do atual ou se houver pequena diferença no relógio. Já o comando que escreve em um .txt é tratado como uma instrução explícita, sendo mantido na fila até o momento exato do agendamento.

Oi Jezebel.
Obrigado por seu feedback.
E gostei bastante da sua explicação.
Isso mostra dominio e entendimento sobre o assunto.
Parabéns de verdade.
Bons estudos.

Boa pergunta, esse comportamento do at/atq costuma confundir mesmo.

O que provavelmente aconteceu
Quando você agendou com now + 3 minutes, há alguns cenários em que o job já pode ter sido executado (ou removido da fila) antes de você rodar o atq, por isso ele aparece vazio:

Ajuste de horário/NTP
Se o relógio do sistema adiantou alguns minutos (sincronização NTP), o horário agendado (ex.: 23:33) pode ter “ficado no passado” e o atd executou o job quase imediatamente. Ao rodar atq logo depois, a fila já estava vazia.

Resolução por minuto (janela de segundos)
O at agenda por minuto inteiro. Se você agendou quando já estava muito perto do próximo minuto, o job pode cair para uma janela muito curta e executar logo após ser criado (especialmente se o sistema estava ocupado). Assim, ao rodar atq, ele já não estava mais na fila.

Fuso horário/DST (horário de verão) ou timezone incorreto
Mudanças de fuso ou uma timezone incorreta podem fazer com que now + 3 minutes caia em um horário “não esperado”, inclusive no passado.

Usuário diferente
O atq lista apenas os jobs do usuário atual. Se você criou o job com um usuário e consultou com outro (ou vice-versa, usando sudo), o atq sem sudo volta vazio.

Dica: sudo atq lista os jobs de todos os usuários.

O job rodou e foi removido
O at remove o job da fila após a execução. Se você chamou atq depois da execução, a fila aparece vazia.

Quando você trocou para 10 minutes, provavelmente criou uma janela de tempo suficientemente longa para que o job permanecesse na fila até o momento em que você rodou o atq, por isso você conseguiu vê-lo.

Como diagnosticar e confirmar

1. Veja o status do serviço atd

systemctl status atd
journalctl -u atd --since "30 min ago"

(Em algumas distros o serviço pode se chamar atd.service.)

1. Verifique data, hora e timezone

date
timedatectl

Procure por ajustes recentes de NTP ou timezone incorreto.

1. Confirme o usuário

Crie e liste como o mesmo usuário.
Para ver tudo: sudo atq.

1. Teste controlado

echo "date > /tmp/teste_at.txt" | at now + 2 minutes
atq
sleep 10
atq

Depois confira /tmp/teste_at.txt e os logs do atd.

1. Confira a saída do job (mail do usuário)

O at envia a saída do job para o mail local do usuário (dependendo da configuração).

mail

(ou verifique /var/spool/at / logs do atd conforme a distro).