crontab não está sendo executado no Fedora 23

1

UPDATE 2

Este é um problema documentado no Fedora 23. Usei a solução alternativa listada aqui link . Parece que está funcionando.

UPDATE

Eu configurei o selinux para o modo permissivo e agora funciona. Alguém pode dar uma ideia do que aconteceu?

ORIGINAL

Usando crontab -e , fiz isso:

* * * * * echo test >> /tmp/a.log

Mas nada parece acontecer.

Nota: há uma linha em branco após a linha.

O que tentei

Eu examinei este Serverfault pergunta mas não consegui encontrar uma solução. Correndo

ps -ef | grep cron | grep -v grep

root       986     1  0 22:07 ?        00:00:01 /usr/sbin/crond -n

Eu não sei o que está errado. Por favor ajude.

    
por jurybrown 18.01.2016 / 04:45

5 respostas

2

Isso foi causado por um bug que foi resolvido por esta atualização em janeiro de 2016 .

    
por 03.03.2017 / 17:34
0

Tem certeza de que não está funcionando?

[nazu@palaceredirect ~]# crontab -l
* * * * * /bin/echo hi >> /tmp/test
[nazu@palaceredirect ~]# ls -l /tmp
-rw-r--r--. 1 nazu nazu    6 Jan 17 20:54 test
  1. Verifique o e-mail da sua conta para ver se algo está denunciando. mail command.
  2. Reinicie o crond se não tiver certeza. %código%
  3. Você pode querer verificar /etc/cron.deny.

Como um aparte, você deve usar o caminho completo dos comandos no cron. Faça isso como um hábito.

    
por 18.01.2016 / 04:59
0

Primeiro, crie um arquivo para testar o Cron Job:

 $touch echo.sh 

Digite seu script no arquivo e tente primeiro manualmente, assim que o script estiver sendo executado corretamente, você poderá programá-lo para o Cronjob.

Definir permissão:

$ chmod +x /path/to/file/echo.sh

Exemplo de trabalho Cron:

 crontab -e

* * * * * /path/to/file/echo.sh

Salvar a entrada.

Você também pode verificar a saída para o cron:

grep CRON /var/log/syslog

OR

tail -f /var/log/syslog | grep CRON
    
por 18.01.2016 / 09:34
0

Lutei contra esse problema por alguns dias e descobri que para executar meus trabalhos do cron do root, basta remover o nome de usuário do crontab.

Isso parece um comportamento inesperado.

Uma atualização quebrou o sistema, depois que um cron de instalação limpa falhou. Além disso, para torná-lo mais estranho, quando eu tentei a correção sugerida eu continuei recebendo erro de número mágico ruim: /

RESOLUTION:
crontab -l [Success]
* * * * * /mnt/nfs/System/sensorSnapshotLoop.sh

crontab -l [failure]
* * * * * root /mnt/nfs/System/sensorSnapshotLoop.sh

Detalhes:

201601201546: this cron entry has no username!
test cron:
crontab -e
* * * * * echo test >> /tmp/a.log
crontab -l
systemctl enable crond
systemctl restart crond
systemctl status crond
cat /tmp/a.log
success!

201601201529: ~5 re-installs later trying different suggestions
#mount nfs share
vi /etc/fstab 
192.168.1.77:/System /mnt/nfs/System            nfs     defaults        0 0
reboot

201601191226: reinstall again
OS reinstall
CentOS-7-x86_64-DVD-1511.iso
features:
Server with GUI
    Network File System Client
    Development Tools
security:
    standard system security profile

201601191033: bad magic after clean install?
#https://bugzilla.redhat.com/show_bug.cgi?id=1263328
gedit mycron.cil
; cron fix
(allow unconfined_t user_cron_spool_t( file ( entrypoint)))
cat mycron.cil
semodule -i mycron.cil
reboot
FAIL! [bad magic number]

#201601190950: still fails w/o nfs access
fix cron <-- no nfs access
mkdir /root/metrics/
cp /mnt/nfs/System/sensorSnapshot.sh /root/metrics/
chmod +x /root/metrics/sensorSnapshotLoop.sh
crontab -e
* * * * * root /root/metrics/sensorSnapshotLoop.sh
crontab -l
systemctl restart crond
systemctl status crond
failed

#201601181929: reinstall/mount nfs share
#mount nfs share
vi /etc/fstab 
192.168.1.77:/System /mnt/nfs/System            nfs     defaults        0 0
reboot

#2016-01-18-1428: noticed failure
upgrade MPSS stack
-> cron failure
*reinstall OS

Obrigado,

Rob

    
por 20.01.2016 / 22:19
0

Recomendamos que você faça o seguinte:

  • Instale algumas ferramentas de solução de problemas do SELinux ##

    yum install setroubleshoot setools
    
  • Verifique o arquivo audit.log e gere um relatório contendo todos os problemas do SELinux descobertos ##

    sealert -a /var/log/audit/audit.log
    
  • Resolva qualquer problema ou crie uma nova política para listá-los em branco usando os comandos fornecidos no final do relatório ##

por 18.01.2016 / 16:42

Tags