Home » Ошибки » Crond ERROR (getpwnam() failed)

Crond ERROR (getpwnam() failed)

Столкнулся сегодня с ошибкой в работе системного Cron. Текст ошибки совершенно не информативный, так что не понятно, в чем конкретно проблема. Начал разбираться самостоятельно, так как по выдаче гугла понял, что причин этой ошибки может быть масса. В итоге нашел решение при проверке /etc/crontab, который использовал для запуска периодических команд.

Теоретический курс по основам сетевых технологий. Позволит системным администраторам упорядочить и восполнить пробелы в знаниях. Цена очень доступная, есть бесплатный доступ. Все подробности по . Можно пройти тест на знание сетей, бесплатно и без регистрации.

Началось все с того, что заметил проблемы с очисткой индексов elasticsearch с помощью curator. Он просто ничего не чистил и индексы распухли, заняв почти все место на диске. Пошел в консоль сервера смотреть, в чем проблема. Ручной запуск curator отработал, удалив устаревшие индексы. Стало понятно, что он просто не запускался. В /etc/crontab было правило на регулярный запуск.

Стал смотреть лог cron и нашел там ошибку:

Jun 3 04:04:01 [localhost] crond[811]: (/usr/bin/curator) ERROR (getpwnam() failed)

По тексту совершенно не понятно, в чем проблема. Быстро заглянув в гугл, понял, что однозначного ответа на причину ошибки не видно. Пошел еще раз смотреть crontab и понял, в чем проблема. Так как использовался системный cron, в нем надо указать имя пользователя, от которого будет работать команда. А я это забыл сделать. Должно быть так:

4 4 * * * root /usr/bin/curator --config /etc/curator/config.yml /etc/curator/action.yml

Пользователя root я забыл указать, поэтому и была ошибка исполнения. Не понятно, почему нельзя было нормально обработать эту ошибку и вывести ее в лог. Ведь очевидно же, что пользователя /usr/bin/curator в системных пользователях просто нет.

Онлайн курс "DevOps практики и инструменты"

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

10 комментариев

  1. Аватар

    Спасибо, помогло.

  2. Аватар
    Евгений

    Добрый день.

    В ubuntu 18 в "crontab -e" отлично отрабатывает скрипт:
    0 12 * * * /root/backupjbars.sh > /dev/null 2>&1

    В CentOS 7 тот же скрипт отрабатывал частично, а именно слал исключительно почтовое уведомление что бекап создан но это было не так. Добавил как в статье в "crontab -e"
    0 2 * * * root /home/ruskan_user/backupjbars.sh > /dev/null 2>&1
    после чего в логах получаю ту же ошибку что в статье, даже ложные почтовые уведомления не приходят что в есть в скрипте. Пробовал вместо root указывать своего пользователя от имени которого логинюсь в систему.

    Одно отличие вижу, что скрипт запускается из разных папок, в случае с убуной в /root, в CentOS из домашней папки пользователя.
    Подскажите направление куда посмотреть.

    • Zerox

      Вы путаете понятия. Пользователя нужно добавлять только если вы используете системный крон. По "crontab -e" открывается cron конкретного пользователя. Там не нужно его указывать.

  3. Аватар

    Какая система интересно?
    На стареньком redhat (5.5) и centos 7 работает без указания имени пользователя.

    • Zerox

      Конкретно эту ошибку увидел на Centos 7. Без указания пользователя системный крон с конфигом в /etc/crontab точно работать не будет.

      • Аватар

        Да, упустил слово "системный cron". У меня от конкретного пользователя запускаются. Спасибо, раньше не знал, что такая проблема возможно. Не приходилось системный задействовать.

        • Zerox

          Я обычно все в системном держу с указанием пользователей. Так удобнее отслеживать все задания в одном месте.

  4. Аватар
    Александр

    Вот он хваленный systemd c journald ничего не понятно

  5. Аватар

    ERROR (getpwnam() failed)
    Ранее встречался с подобной ошибкой, когда имел привычку подолгу держать консоли открытыми,
    и запускать скрипты из папки с приложением. А эту папку автоматика перезаписывала с обновлением версии.
    Поэтому название папки оставалось прежним, а вот её идентификатор менялся, и скрипт падал с ошибкой.

    Починилось это просто - выйти из папки и зайти обратно. Но информации в гугле действительно не хватало.

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.