Много процессов CRON в списке, нормально ли это?

Question

[DuD]

Раньше как-то не обращал внимания, но недавно отсортировал процессы по названию и увидел странную картину. К примеру, CRON'a 42 шт, как-то многовато =). Нормально ли это? Или это 1 процесс и я просто не так смотрю? Я ориентировался на PID, он то разный.



Или вот файл /root/backup/do-backup.sh в кроне стоит 1 раз с запуском в 0 часов. А на скрине ниже их несколько.


Вот так выглядит задача:
* 0 * * * /root/backup/do-backup.sh >> /root/backup/log.log 2>&1

Answer 1

[dykky]

А это нормально, что /USR/SBIN/CRON - заглавные? В юнихах регист букв играет значение. Это вообще крон???

Comments

[DuD]

Да, это нормально. Да это cron

[dykky]

За 30, что вожусь с юнихами, не встречал крона капсом. Вы меня удивили.

[DuD]

Я буду рад даже это подтвердить если скажете как отличить оригинальный cron от предположительно поддельного)

[dykky]

Крон, который крон, лежит где-то в /usr. /USR - это уже не нормально. /USR/SBIN - просто фантастика. Всё что в /USR/SBIN - предмет детального исследования. Можно конечно предположить, что Вы используете файловую систему не чувствительную к регистру, FAT32 на пример... Но у вас есть в списке процессов /usr/sbin/mysqld - в нижнем регистре.

[DuD]

@dykky
вот что есть:
~ $ whereis cron
cron: /usr/sbin/cron /etc/cron.weekly /etc/cron.hourly /etc/cron.monthly /etc/cron.d /etc/cron.daily /usr/share/man/man8/cron.8.gz

А где обычно он лежит?

[dykky]

Зависит от вашей системы. У линухов чаще всего /usr/sbin/cron . НО /usr/sbin/cron и /USR/SBIN/CRON - это абсолютно разные вещи.
Вы попробуйте посмотреть с помощью lsof -p 15351 (где 15351 - PID капсованного крона) строки с полем FD типа "cwd" и "txt" - текущий каталог и полный путь исполняемого файла. ИМХО, если на картинках не было опечаток и крон - капсованный, система взломана и занимается чем-то не хорошим.

[DuD]

@dykky мне кажется это какая то ошибка в htop.

# cd /USR/SBIN
bash: cd: /USR/SBIN: No such file or directory

[dykky]

:):):) Создали каталог, запустили прогу, удалили прогу с каталогом. Файл проги остаётся открытым и будет неприкосновенным до завершения проги (пройдёт сискол закрытия файла, который окончательно удалит удалённый файл) или перезагрузки системы. Это только в шинде открытый файл удалить сложно, в юнихе такой функционал изначально был нормальным, при чём после удаления даже форк нормально работает. Чаще всего используется хацкерами для обмана начинающих админов, ну ещё некоторые так заботятся об удалении временных файлов или скрытия рабочих данных. lsof поможет. Обязательно проверяйте скрипты запуска системы - туда наверняка что-то добавили.

Answer 2

[okneigres]

Переодически падали сервера из-за такой вот проблемы с кронами в статусе D. Гугление по англоязычным ресурсам привело к нахождению вот этого: "I have seen this happen before, it was always associated with a developing disk or disk controller fault. Check your hardware fault logs too."

В таком состоянии сервак вообще вел себя странно, попытки записать что-то на диск вешают процессы, а потом и всю систему (хотя, чтение отрабатывало). У себя на серваках я обновил ядро до последнего, попутно решились другие странные проблемы. Пока наблюдаю.

Answer 3

[Павел Селиванов]

Скорее всего, do-backup.sh работает слишком долго, или вообще виснет. Чтобы убедиться, что это именно так, а не особенность работы скрипта, который создаёт кучу форков, можно использовать ps -o pid,cmd,lstart -p $PID1,$PID2,...
по PID всех процессов - покажет время, когда какой из них был запущен.

Comments

[DuD]

Нет, скрипт точно не создаёт форков. Там всего то 5 строк. Что то вроде "$(which tar) -c /etc/ > $TMPPATH/$THEDATE-settings.tar 2> /dev/null;" и т.п.

Answer 4

[Игорь]

Покажите сам crontab или файл где задачи cron-а прописаны. Может где-то в нотации ошиблись и они у вас часто запускаются.
Проверить также можно по логам, там будут сообщения во сколько какие задачи запущены.

Рекомендую также обратить внимание на нагрузку по диску. У вас на скриншотах половина процессов в состоянии D. Это означает, что в текущий момент диск не справляется и заставляет процессы ждать.

Comments

[DuD]

Это скрипт резервного копирования. И он действительно даёт нагрузку на диск. Просто не могу понять почему процессов так много, если запуск всего 1 в сутки.
В логах я вижу (grandchild #15163 failed with exit status 2) но 15163 это pid другого задания. Может ли CRON из за ошибки одного задания перезапускать все?