Почему новые задания cron игнорируются, если crond не перезапущен в SLES?

Почему новые задания cron игнорируются, если crond не перезапущен в SLES?

Я добавил новое задание cron для пользователя (SUSE LINUX Enterprise Server 9.4):

# su - XXX
$ crontab -e

и вот что я добавил:

* * * * * echo `date` >> /home/XXX/a.txt

но a.txt не создается... он будет создан ТОЛЬКО тогда, когда root перезапустит crond...

В:Почему?

ОБНОВЛЯТЬ:

machine:~ # chage -l XXX
Minimum:    1
Maximum:    99999
Warning:    7
Inactive:   -1
Last Change:        Apr 11, 2011
Password Expires:   Never
Password Inactive:  Never
Account Expires:    Never
machine:~ # 

чтобы срок действия пользователя или его пароля не истек.

ОБНОВЛЕНИЕ: версия cron:

cron-3.0.1-920.18

и я попытался добавить новый crontab для пользователя root.. то же самое :D новые задания root cron тоже не запускаются.. :Dпохоже, что "crontab -e" не перезагружает CROND или что-то в этом роде...

решение1

Я попробовал приведенный выше код, и он отлично заработал на Red Hat Fedora 14.

* * * * * echo `date` >> /home/saml/a.txt

Вывод файла:

$ tail -f a.txt 
Fri Oct 4 14:38:01 EDT 2013
Fri Oct 4 14:39:01 EDT 2013
Fri Oct 4 14:40:01 EDT 2013

Что попробовать

  1. Можете ли вы подтвердить, что crondслужба работает:

    $ sudo service --status-all |& grep crond
    crond (pid  1673) is running...
    
  2. Подтвердите настройку каталога спула cron.

    $ rpm -qf $(type -P /usr/sbin/crond)
    cronie-1.4.8-2.fc14.x86_64
    
    $ rpm -ql cronie | grep '/var'
    /var/spool/cron
    

    Перечислите, каким бы ни был ваш каталог, мы проверяем его существование и разрешения здесь:

    $ sudo ls -ld /var/spool/cron/
    drwx------. 2 root root 4096 Oct  4 14:37 /var/spool/cron/
    
    $ sudo ls -l /var/spool/cron/
    total 4
    -rw------- 1 root root  0 Sep 16 23:47 root
    -rw------- 1 saml root 42 Oct  4 14:37 saml
    
  3. SELinux

    Имеют ли задания cron доступ через SELinux для записи в ваш каталог /home/XXX?

    Быстрой проверкой будет временное отключение принудительного применения SELinux и проверка того, решит ли это вашу проблему.

    $ getenforce
    Disabled
    

    Если он включен, отключите его:

    $ sudo setenforce 0
    

решение2

strace crontab -e

решил это... не знаю как... но теперь работает... но все, что я хотел сделать, это проверить низкоуровневые "операции" в crontabs..

Связанный контент