Установите nagios3 на debian способным, файл, не найденный ошибкой

Эта команда займет много времени для выполнения (так как она исследует каждый файл в системе), но она должна найти файл:

find / -type f -print0 | xargs -0 grep -w 'TMOUT=' /dev/null

Альтернативный подход должен узнать, при каких обстоятельствах он установлен, например, путем проверки, установлен ли он, когда оболочка не является оболочкой входа в систему (env -i bash) и ли это (env -i bash --login). Вы могли вручную регистрировать файлы $HOME, например, .profile, .env, .bashrc или .bash_profile. Существуют также некоторые файлы в /etc/ которые указывают переменные среды; это могло быть установлено в любом из них.

Если Ваша оболочка входа в систему ksh, Вы найдете это $TMOUT установлен самой оболочкой ksh.


Править: объяснить некоторые менее очевидные функции командной строки выше:

Идиома find ... -print0 | xargs -0 ... довольно распространено. Точка использования -print0 вместо значения по умолчанию -print это, имена файлов завершаются с NUL ASCII в случае -print0. Это означает, что имена файлов, содержащие фактическую новую строку, будут правильно представлены. Передача -0 опция к xargs просто делает xargs поймите ту же конвенцию.

Практика стандартной передачи /dev/null как первый аргумент grep также стоит объяснить. Так как Вы только получаете конец файла при чтении из /dev/null, это никогда не будет соответствовать никакой непустой строке grep. Следовательно не будет никаких хитов для того файла. Мы только указываем его на grep командной строке для привыкания правильно со случаем где заключительное время xargs выполнения grep, существует только один остающийся файл, который будет искаться. Если grep имеет только один аргумент файла, он перечисляет хиты, не указывая командную строку. Как так:

~/tmp/t$ echo hello > a
~/tmp/t$ echo hi > b
~/tmp/t$ grep '^h.*' a
hello
~/tmp/t$ grep '^h.*' a b
a:hello
b:hi
2
16.08.2013, 16:14
1 ответ

Проверьте журналы Apache на дополнительную информацию. Обычно существует 2 журнала, access.log и error.log. Оба могут быть полезными. access.log покажет Вам URL, к которому получили доступ наряду с http состоянием (число такой как 200, что означает OK или 404, что означает ошибку).

Журнал ошибок может показать, что Вы производите из любых сценариев CGI, которые, возможно, перестали работать. Обычно сценарий CGI или не настроен правильно или библиотеки, в которых он нуждается, отсутствуют. Так как Nagios является Perl, базирующимся, он мог бы пропускать модули Perl, например.

1
27.01.2020, 22:23
  • 1
    спасибо приятель, я обновил вопрос. –  sazary 16.08.2013, 16:15
  • 2
    @sazary - Хорошо, таким образом, то, что это возвращает 200 в журналах, означает, что Apache может обслужить запрос очень хорошо. Сценарий это имеет проблемы, является check_http, я посмотрел бы в nagios файлах журнала для получения дополнительной информации теперь. –  slm♦ 16.08.2013, 16:17
  • 3
    , где они? я посмотрел на /var/log/nagios3/nagios.log но это не имело никакой ошибки. и я проверил /etc/nagios3/nagios.cfg и каждая конфигурация журнала была установлена на 1. также, ps aux | grep check_http возвраты ничто, любой делает whereis check_http. –  sazary 16.08.2013, 16:26
  • 4
    @sazary - плагины обычно не находятся на пути. Попробуйте команду locate check_http. Можно также узнать, где они путем заглядывания nagios.cfg. –  slm♦ 16.08.2013, 16:43
  • 5
    Это не это. check_http является строкой агента пользователя nagios плагина, который проверяет, что Ваш веб-сервер все еще работает. Необходимо найти запись для браузера, не для check_http –  Wouter Verhelst 04.07.2015, 09:49

Теги

Похожие вопросы