Ошибка Cron Authentication Failure в Linux?
Кроме установки loglevel из KCL, вы также можете настроить kernel.printk sysctl так, чтобы максимальный уровень отражал то, что вы хотите, и сохранялся после загрузки.
Что касается дальнейшего уточнения в комментарии:
проблема в том, что syslog и dmesg переполнены бесполезными отладочными журналами, и таким образом реальные предупреждения и ошибки легче пропустить.
Я бы просто использовал logrotate в задании cron для перемещения файлов с пути после перезагрузки:
root ~ $ crontab -l
@reboot /usr/sbin/logrotate --force /root/rotate-boot-messages
@reboot /bin/dmesg -c
root ~ $ cat /root/rotate-boot-messages
"/var/log/dmesg" {
copytruncate
notifempty
missingok
dateext
}
"/var/log/syslog" {
copytruncate
notifempty
missingok
dateext
}
Тогда вы начнете все с чистого листа, так сказать, с ограниченным сбросом отладочных данных в журналы.
Не могли бы вы проверить разрешение и право собственности на файл cron для пользователя, использующего для запуска cron в /var/spool/cron/crontabs?
Также если учетная запись пользователя заблокирована? Поэтому проверьте запись файла /etc/passwd для этого пользователя. Срок действия пароля не должен быть истек или дней, установленных для истечения срока действия пароля. Если все в порядке, вам нужно проверить, все ли в порядке с файлами /etc/cron.allow и /etc/cron.deny и не содержат ли они пользователя, запускающего cron. Увидев ваш ответ, я верю, что это пользователь root, и я надеюсь, что файлы разрешения и запрета в порядке.
Затем вам нужно проверить /etc/security/access.conf и посмотреть, поможет вам добавление следующей записи или нет
+ВСЕ :cron cron
, но убедитесь, что вы сделали резервную копию access.conf и запись добавлена ДО/ВЫШЕ -:ВСЕ :ВСЕ
Теперь, если и это не поможет, вам нужно будет проверить модуль аутентификации, который вы настроили в системе, kerberos, pan, ldap и т. д. Я бы посоветовал вам пройти описанное выше упражнение и сообщить нам об этом дальше.
проверить права пользователя на файл cron для запуска cron в /var/spool/cron/crontabs.
-rw------- 1 root root 338 Dec 8 12:49 root
Я подозреваю, что это было вызвано удалением пользователя, а его запись в crontab на тот момент не была удалена. По сути, crontab не может запустить команду от имени пользователя, поскольку пользователя не существует -, так что проверьте и это!
Я обычно видел это, если срок действия учетной записи пользователя истек, что может произойти и с пользователем root.
Чтобы проверить, suпользователю и проверьте, получили ли вы Authentication Failure, например.:
$ sudo su -
Your account has expired; please contact your system administrator
su: Authentication failure
(Ignored)
Чтобы исправить:обновите срок действия на аккаунте:
sudo chage -M 300 root
Или любое другое имя пользователя, с которым у вас возникли проблемы, вместо rootвыше.
Одна вещь, которую я обнаружил, была, когда pam_tally2был установлен. В journalctl -u cronя увидел
May 26 08:12:01 PublicProxy CRON[16303]: pam_tally2(cron:setcred): bad number supplied: unlock_time=never
Вот не -рабочая строка:
auth required pam_tally2.so silent even_deny_root deny=3 unlock_time=never
Вот как это выглядит после исправления:
auth required pam_tally2.so silent even_deny_root deny=3 unlock_time=0
Я решил эту проблему с помощью следующих шагов:
- Пожалуйста, проверьте, не истек ли срок действия пароля этого пользователя.
chage -l scfuser - Если срок действия истек, установите его с помощью следующего шага :
passwd scfuser