Частое зависание в 4 утра

запускается у вас в 4:02 часть, которая описана в /etc/cron.daily, и которую вы боитесь показать, и хрен его знает, что у вас там записано.

Что именно нужно показать? Вывод я показал:
[console]
[root@ cron.daily]# ls -1
certwatch*
logrotate*
msec@
rpm*
tmpwatch*
[/console]

Что нужно еще показать? Я не совсем понял... Тут ни какого криминала - я только за то то бы Вы помогли и готов предоставить все данные. Говорите только плиз поконкретнее что именно нужно от меня, что бы помочь с решение проблемы.

brullek написал:

Как восстановить?

Если у вас БД postgres не используется, т о initdb, если используется, то из бекапа или WAL

Очень маловероятно что БД посыплаь, т.к. весь механизм сейчас работает и функционирует отлично. Но по ночам что-то приводи к зависанию.

brullek написал:

Тут ни какого криминала

наверное это rpm. но точно я не знаю.
поставьте в начале каждого файла

echo "$0" >>/var/log/cron1.log
date >>/var/log/cron1.log

тогда каждый файл будет писать в этот лог своё имя, и во сколько он начал работать.
таким образом мы узнаем, какаой из них виснет.

ЗЫЖ не в самое начало конечно, а после первой строки

#!/bin/sh

а тормозить может что угодно. и RPM, и logrotate.

Во все скрипты ввел логирирование на входе и выходе из скрипта. Буду ждать очередного зависания (p.s. бывает месяцами все работает, а бывает каждую ночь подвисает).

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

P.S:

а тормозить может что угодно. и RPM, и logrotate.

Вопрос не о тормозах, а о глухом зависание, которое происходит с 4 ночи до 9 утра, пока я физически сервер не отправлю в ребут.

brullek написал:

Вопрос не о тормозах, а о глухом зависание, которое происходит с 4 ночи до 9 утра, пока я физически сервер не отправлю в ребут.

"глухое зависание" это тоже обычно тормоза. например logrotate умеет сжимать файлы, причём современные сжиматели жрут много памяти - если памяти не хватит, то либо всё рухнет если нет свопа, либо всё будет "работать", только в 1000 раз медленнее, если своп есть. и то и другое "глухое зависание". также может порушиться БД RPM, это тоже приведёт к зависанию - перезагрузить-то можно, но следующей ночью всё повторится.

Лично я считаю, что в RH неправильно сделали, что засунули все задачи на 4 утра, лучше-бы их равномерно раскидать по промежутку времени, когда загрузка небольшая... тогда достаточно просто определить время зависания.

также может порушиться БД RPM, это тоже приведёт к зависанию - перезагрузить-то можно, но следующей ночью всё повторится.

Тут другой случай. Я принудительно вызывал все скрипты с крона днем, смотрел как они отрабатываються. Все работает норм. Две ночи уже все норм. Это зависит от каких-то факторов, которые мне не известны... мб интеренет падает, или мб происходит конфликт выполняемых ежечастных скриптов (первая минута каждого часа... там только /usr/bin/msec отрабатывается) с ежедневными (вторая минута пятого часа, список отрабатываемых скриптов показывал выше). В прочем crontab я показывал уже...

Речь идет не о зависание каждую ночь, а о зависаниях, которых может месяц не быть, а могут 2 ночи подряд повториться...

brullek, дык я о том и говорю - если БД рухнула, она и на следующее утро опять рухнет...
а по времени разнесите конечно ежечасные с ежедневными (первое число в crontab).

drBatty, спасиба за советы.
А файл /etc/crontab можно из MC через F4 редактировать? или нужно специальной утилитой его править, как пользовательские задания?

brullek,для редактирования crontab, необходимо использовать crontab -e , только надо знать как работает vi =)

P.S. не запускайте crontab без ключей, иначе все задания которые есть затрете, перед использованием команды, ознакомьтесь с руководством пользователя, проще говоря man 5 crontab

i2ks написал:

brullek,для редактирования crontab, необходимо использовать crontab -e , только надо знать как работает vi =)

P.S. не запускайте crontab без ключей, иначе все задания которые есть затрете, перед использованием команды, ознакомьтесь с руководством пользователя, проще говоря man 5 crontab

полностью согласен.

Однако, есть возможность прописать любимый текстовый редактор (mcedit например)

man crontab написал:

crontab manipulates the crontab for a particular user. Only the superuser may specify a dif-
ferent user and/or crontab directory. Generally the -e option is used to edit your crontab.
crontab will use /usr/bin/vi or the editor specified by your VISUAL environment variable to
edit the crontab.

Спустя месяц без отказной работы, сегодня снова утром было зависание компьюетра.
Так, новые детали нашел в соей проблеме:
Запуск ежедневного задания @msec (/usr/share/msec/security.sh) по логам успшно происходит, а EXIT'a из задания небыло.

Советуем, кто чего порекомендует :)

brullek написал:

/usr/share/msec/security.sh

brullek написал:

Советуем, кто чего порекомендует

порекомендую скрипт проанализировать или здесь выложить.

Скрипт обязаттельно проанализирую ))
Еще бы понимать в нем хоть полоивну ))

ну я щас дополнительно по секциям ввел логироирование в срипте, буду по логам смотреть на каком учатке отваливается.

После анализа скрипта вычесленно место зависания:

### rpm database check
if [[ ${RPM_CHECK} == yes ]]; then
    rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE}\t%{INSTALLTIME}\n" | sort > ${RP
M_QA_TODAY}
    rm -f ${RPM_VA_TODAY}.tmp
    nice --adjustment=+19 rpm -V `cut -f 1  < ${RPM_QA_TODAY} | grep -v '^dev-[0
-9]'` | grep '^..5' | sort > ${RPM_VA_TODAY}.tmp
    grep -v '^..........c.'  ${RPM_VA_TODAY}.tmp | sed 's/^............//' | sor
t > ${RPM_VA_TODAY}
    grep '^..........c.'  ${RPM_VA_TODAY}.tmp | sed 's/^............//' | sort >
 ${RPM_VA_CONFIG_TODAY}
    rm -f ${RPM_VA_TODAY}.tmp
fi

Сейчас разбил этот скрипт на части, и ввел лог по строчно, буду ждать следующих зависаний.
Хотя мб кто-то из Вас уже сейчас на 100% поставит диагноз и даст рекомендации как поправить )

brullek написал:

Хотя мб кто-то из Вас уже сейчас на 100% поставит диагноз и даст рекомендации как поправить

легко - это обновления. Если они есть и их много - комп виснет. Такое бывает, после нахождения дыры в какой-то распространённой либе - приходится фиксить половину пакетов. Сносить и ставить заново пол-системы :[
Не лечится...

drBatty написал:

Не лечится...

ну не совсем... есть паллиатив.

[console]$ xscreensaver-command -time
XScreenSaver 5.12: screen non-blanked since Wed Apr 20 09:36:48 2011 (hack #164)
[/console]
видно, что экран не заблокирован. А следовательно я там чё-то набираю.
Если он заблокирован скажем полчаса - можно и обновится, пока хозяин спит...

ясн, буду думать, спасиб