Прежде всего создайте файл для проверки задания Cron:

 $touch echo.sh 

Введите свой сценарий в файл и сначала попробуйте его вручную, как только сценарий будет выполнен правильно, вы можете запланировать его для задания Cron.

Установить разрешение:

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

Пример задания Cron:

 crontab -e

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

Сохранить запись.

Вы также можете проверить вывод для cron:

grep CRON /var/log/syslog

OR

tail -f /var/log/syslog | grep CRON

Вы уверены, что это не работает?

[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. Проверьте почту вашего аккаунта, чтобы увидеть, сообщает ли что-нибудь. mail command.
2. Перезапустите crond, если вы не уверены. systemctl restart crond.service
3. Возможно, вы захотите проверить /etc/cron.deny.

В качестве дополнения, вы должны использовать полный путь команд в cron. Делайте это по привычке.

Я бы рекомендовал вам сделать следующее:

• Установите некоторые инструменты для устранения проблем SELinux ##

  yum install setroubleshoot setools
  

• Просканируйте файл audit.log и создайте отчет, содержащий все обнаруженные проблемы SELinux ##

  sealert -a /var/log/audit/audit.log
  

• Либо устраните все проблемы, либо создайте новую политику для их исключения из белого списка, используя команды, приведенные в конце отчета ##

Я боролся с этой проблемой несколько дней и обнаружил, что для выполнения моих заданий корневого cron просто удалите имя пользователя из crontab.

Это кажется неожиданным поведением.

При обновлении система сломалась, а затем после сбоя чистой установки cron. Вдобавок, чтобы сделать это еще более странным, когда я попробовал предложенное исправление, я продолжал получать плохую ошибку с магическим числом: /

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

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

Подробности:

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

Спасибо,

Роб

Это было вызвано ошибка, которая была устранена этим обновлением в январе 2016 года .