Perguntas[cron](unix)

Adicionei o seguinte ao /etc/crontabmeu sistema Linux:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
0 0 */1 * * root chmod +x /root/source/auto-renew.sh && /root/source/auto-renew.sh >> /root/source/auto-renew-cron.log 2>&1

No entanto, quando executo agora crontab -l, ele não mostra esta tarefa do crontab:

[root@iZm5e2jhfbrshckqh6qdbuZ cron.d]# crontab -l
45 6 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

Por que não está crontab -lmostrando a /etc/crontabtarefa?

Este é o registro:

[root@iZm5e2jhfbrshckqh6qdbuZ cron.d]# journalctl -u crond
-- Logs begin at Wed 2024-11-20 15:32:06 CST, end at Wed 2025-01-01 13:54:30 CST. --
Nov 20 16:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1444408]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 17:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1486477]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 18:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1528604]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 19:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1570709]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 20:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1612872]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 21:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1655340]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 22:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1697643]: (root) CMD (run-parts /etc/cron.hourly)
Nov 20 23:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1739698]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 00:00:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1781104]: (root) CMD (chmod +x /root/source/auto-renew.sh && /root/source/auto-renew.sh >> /root/source/auto-renew-cron.log 2>&1)
Nov 21 00:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1781971]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 00:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1781980]: Anacron started on 2024-11-21
Nov 21 00:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1781980]: Normal exit (0 jobs run)
Nov 21 01:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1824103]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 01:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1824112]: Anacron started on 2024-11-21
Nov 21 01:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1824112]: Normal exit (0 jobs run)
Nov 21 02:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1866166]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 02:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1866175]: Anacron started on 2024-11-21
Nov 21 02:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1866175]: Normal exit (0 jobs run)
Nov 21 03:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1908181]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 03:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Anacron started on 2024-11-21
Nov 21 03:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Will run job `cron.daily' in 50 min.
Nov 21 03:01:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Jobs will be executed sequentially
Nov 21 03:51:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Job `cron.daily' started
Nov 21 03:51:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Job `cron.daily' terminated
Nov 21 03:51:01 iZm5e2jhfbrshckqh6qdbuZ anacron[1908190]: Normal exit (1 job run)
Nov 21 04:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1950218]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 05:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[1992303]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 06:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2034382]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 07:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2076636]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 08:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2118744]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 09:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2160824]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 10:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2203126]: (root) CMD (run-parts /etc/cron.hourly)
Nov 21 11:01:01 iZm5e2jhfbrshckqh6qdbuZ CROND[2245206]: (root) CMD (run-parts /etc/cron.hourly)

Aqui na França, meia-noite 00:00 é o fim do dia, em inglês é o começo do dia.

Em uma tabela cron, se um lote for agendado para 00:00 de sexta-feira, ele terminará na manhã de sexta-feira.

Minha pergunta é: alterar o local e o horário altera a definição de meia-noite?

Se eu configurar um servidor com a localidade francesa, o lote agendado para 00:00 de sexta-feira terminará na manhã de sábado?

Tenho esta configuração para detalhes de log:

/opt/freeradius/logs/*/detail {

daily
rotate 4
compress
delaycompress
missingok
notifempty
create 0640 root root
sharedscripts
maxsize 500M
postrotate
    /bin/systemctl reload freeradius > /dev/null 2>/dev/null || true
endscript
}

Tenho esses logs antigos com logs novos:

[root@freeradius01 192.168.17.10]# pwd
/opt/freeradius/logs/192.168.17.10
[root@freeradius01 192.168.17.10]# ll
total 56919724
-rwxrwxrwx 1 root root 21048752215 Aug 14 23:59 detail-20240814
-rwxrwxrwx 1 root root 21617187765 Aug 15 23:59 detail-20240815
-rwxrwxrwx 1 root root  5988044800 Aug 16 23:59 detail-20240816
-rwxrwxrwx 1 root root     5947392 Sep 25 23:59 detail-20240925
-rwxrwxrwx 1 root root  7478423552 Oct 21 23:59 detail-20241021
-rwxrwxrwx 1 root root  1907452140 Oct 22 11:19 detail-20241022
[root@freeradius01 192.168.17.10]#

Ao executar o logrotate manualmente e forçado com verbos, tenho este resultado:

[root@freeradius01 192.168.17.10]#  /usr/sbin/logrotate -v -f /etc/logrotate.d/radiusd
reading config file /etc/logrotate.d/radiusd
Reading state from file: /var/lib/logrotate/logrotate.status
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
..
..
Creating new state

Handling logs


rotating pattern: /opt/freeradius/logs/*/detail  forced from command line (4 rotations)
empty log files are not rotated, log files >= 524288000 are rotated earlier, old logs are removed
considering log /opt/freeradius/logs/*/detail
not running postrotate script, since no logs were rotated


[root@freeradius01 192.168.17.10]# ll
total 56919724
-rwxrwxrwx 1 root root 21048752215 Aug 14 23:59 detail-20240814
-rwxrwxrwx 1 root root 21617187765 Aug 15 23:59 detail-20240815
-rwxrwxrwx 1 root root  5988044800 Aug 16 23:59 detail-20240816
-rwxrwxrwx 1 root root     5947392 Sep 25 23:59 detail-20240925
-rwxrwxrwx 1 root root  7478423552 Oct 21 23:59 detail-20241021
-rwxrwxrwx 1 root root  1968389637 Oct 22 11:22 detail-20241022
[root@freeradius01 192.168.17.10]# grep "detail"   /var/lib/logrotate/logrotate.status
"/var/log/radius/radacct/*/detail" 2024-3-5-3:0:0
"/opt/freeradius/logs/*/detail" 2024-3-5-3:0:0
[root@freeradius01 192.168.17.10]# date
Tue Oct 22 11:22:45 WAT 2024
[root@freeradius01 192.168.17.10]#

Então a rotação de log não está sendo executada apesar de eu tê-la executado manualmente / também os logs antigos não estão compactados!!?

Gostaria de um cron job rodando a cada hora para o speedtest cli e registrá-lo em um arquivo csv com hora e data ( https://www.speedtest.net/apps/cli ). Então posso executá-lo dessa forma

0 * * * * speedtest -p no -f csv >> /home/almalinux/speedtest.csv

como posso injetar a saída do comando "date" como a primeira coluna (entrada) para cada teste de velocidade?

Baseado na resposta abaixo. O comando de trabalho é este. E funciona a partir do terminal:

0 * * * * (printf "\%s," "$(date)"; speedtest -p no -f csv) >> /home/almalinux/speedtest.csv

Mas não funciona no CRON.

Tenho uma programação no meu crontab pessoal em um sistema Alpine Linux 3.20 que roda às 00:10 de terça a domingo (ou seja, todos os dias da semana, exceto segundas-feiras):

10 0 * * 2-7  "$HOME/local/sbin/backup.sh" prune-daily

Isso parece disparar nas segundas-feiras também. Por quê?

_{Note que meu relatório inicial deu os sintomas como "Não roda aos domingos". Eu me lembrei errado do que aconteceu, desculpe. Corrigi a descrição dos sintomas após investigá-los mais a fundo. O cronograma do crontab está correto, como estava desde o início.}

Eu mudei /etc/cron.d/filenamee adicionei uma nova tarefa.

* * * * * /bin/bash /root/scripts/scriptname.sh

Mas esse trabalho não é executado. Reiniciar o Cron não ajuda.

Eu tenho o mesmo tipo de trabalho para 10 instâncias paralelas do postgres em um único servidor. Eles devem funcionar a cada 6 horas, mas não todos no mesmo horário.

11 */6 * * * my_commandcorre em 0:11, 6:11, 12:11,18:11

Para que eu possa separá-los um do outro com os meios de definir o minuto (30 minutos no máximo). Mas eu gostaria de mais, como correr 0,6,12,18versus correr, ou seja2,8,14,20

então minha pergunta é ... existe uma maneira de ter outro trabalho em execução 2:11, ou seja 8:11, , 14:11,20:11

ou devo dizer 11 */6 * * * sleep 120m && my_commandpara a execução alternativa?

Eu tenho um cron job que reproduz um arquivo de áudio mpvem um dos meus servidores domésticos executando o Void Linux. Não consigo ouvir nenhum som até fazer o ssh no servidor e iniciar o pipewire manualmente, após o que ele funciona para todas as execuções futuras do cron job.

/usr/bin/pipewire &
/usr/bin/sleep 1
/usr/bin/pactl set-sink-volume @DEFAULT_SINK@ 100%
/usr/bin/mpv <path-to-the-audio-file>

Usei o caminho completo para tudo, pois aprendi que os crons são executados em ambientes mínimos onde nem tudo está no formato $PATH. O sleepobjetivo é garantir que o pipewire esteja pronto, pois tive um problema ao definir o volume do coletor logo após iniciar o pipewire. Parece funcionar para mim em outro lugar, então usei aqui também.

DR: Preciso fazer ssh no servidor e iniciar o pipewire pelo menos uma vez para que o áudio seja reproduzido.

Existe uma maneira de iniciar o pipewire mesmo após uma nova reinicialização?

Mencionado em um comentário nesta postagem Como os arquivos em /etc/cron.d são usados? :

As pessoas podem não perceber que "os nomes dos arquivos devem estar em conformidade com os requisitos de nome de arquivo do run-parts" (consulte man cron do Debian). Portanto, os nomes de arquivos em /etc/cron.d/ que correspondem ao shell glob [!A-Za-z0-9_-] são ignorados! Portanto, coisas como *.dpkg-dist ou vi-backups *~ não causam danos, mas se você criar acidentalmente /etc/cron.d/very_important.crontab, isso será ignorado devido ao arquivo . iniciar!

Existe alguma restrição nas pastas cron.daily , cron.hourly, cron.monthly etc. pelos nomes de arquivos acima com o '.' símbolo nos nomes dos arquivos acima? Se não, então por quê? Por que a restrição de nomenclatura está apenas em /etc/cron.d/?

Nos últimos dias tenho observado processos estranhos em um de nossos servidores. Na maioria das vezes, vejo várias instâncias do executável 10e, às vezes 4 , consome muitos recursos da CPU. Quando examinado isso, tenho visto que o processo é iniciado pelo cron logo após iniciar um processo com executável cpu_hu. O que aparentemente é estranho ao meu sistema e a pesquisa simples não resolveu nada.

Em seguida, examinou o cpu_huprocesso, examinou a localização do exe e depois removeu adequadamente (a localização na imagem aponta para um local para um pequeno projeto em que nossa equipe está trabalhando)

mesmo que eu tenha removido o binário, após a reinicialização ele apareceu em um local diferente

e os executáveis 10, 4iniciados na memória (sem localização física do executável)

Excluí cpu_huo binário de todos os locais do sistema, interrompi o processo e reiniciei, mas depois de algum tempo cpu_huo binário aparece em outro lugar. Por enquanto parei o crond e eliminei os respectivos processos. O que parecia ter impedido o processo de recomeçar.

Neste ponto, tenho certeza de que é malicioso. Como posso me livrar disso ou melhor, encontrar o ponto de partida desse malware para evitar que ele seja iniciado.