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

Crond ERROR (getpwnam() failed)

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .

Началось все с того, что заметил проблемы с очисткой индексов 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 в системных пользователях просто нет.

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

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

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

    Добрый день.

    В 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 конкретного пользователя. Там не нужно его указывать.

  2. Аватар

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

    • Zerox

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

      • Аватар

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

        • Zerox

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

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

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

  4. Аватар

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

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

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

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

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