отладка демона Perl, который завершает работу при запуске

Я установил и настроил Демон удаленной внешней команды Nagios в нашем окне nagios, но я обнаружил, что как только он запускается, он завершает работу без каких-либо ошибок.

Сервер Ubuntu 12.10, и nrecd был установлен из файла tar в виде простого процесса - создайте каталог конфигурации, добавьте строку в /etc/rc.local, скопируйте файл bin в /usr/bin и выполните настройку.

когда я запускаю sudo nrecd, ответ Server nrecd started successfully. PID = 10698., однако, если я сразу запускаю ps -A | grep 10698, я ничего не вижу. Точно так же netstat -an показывает, что служба не прослушивает 5665.

в файле журнала я вижу только записи, когда я остановил сервер (даже это ложь, учитывая все, что на самом деле происходит, когда я sudo nrecd stop удаляю устаревший pid-файл).

в /usr/bin/nrecd я просмотрел код строки, которая печатает строку «Сервер успешно запущен», и добавил несколько других print:

my $mypid = daemonize();
print "Server $basename started successfully. PID = $mypid.\n" if $mypid;
print "line 122";
create_pid_file( $mypid, $pidfile );
print "line 124";
change_privileges( $user, $group );
print "line 126";
lock_stdio();
print "line 128";
chmod( 0666, $logfile );
print "line 130";
logmsg( "Server $basename Started Successfully.\n" );

Теперь я вижу:

Server nrecd started successfully. PID = 10698.
line 122line 124line 126

Что говорит мне, что проблема в lock_stdio(); суб. Это недалеко от того места, где я застрял. Я не программист на Perl, но даже для меня все эти подпрограммы выглядят стандартно — просто перенаправляем ввод-вывод на /dev/null. Я попытался запустить его с помощью perl -d, но все, что я сделал, это прошелся по файлу строка за строкой и не узнал ничего нового.

Сам саб это:

sub lock_stdio {
    open( STDIN,  '<', '/dev/null'  ) or croak "Can't read /dev/null: $!";
    open( STDOUT, '>>', '/dev/null' ) or croak "Can't write to /dev/null: $!";
    open( STDERR, '>>', '/dev/null' ) or croak "Can't write to /dev/null: $!";
    return();
};

Есть ли что-нибудь, что кто-то может предложить с точки зрения разработки этого? Если он действительно изолирован от этого 3-строчного сабвуфера, я чувствую себя нелепо, не имея возможности найти проблему (как я уже сказал, для меня это выглядит стандартно). Любая помощь приветствуется!


person Chris O'Kelly    schedule 22.01.2013    source источник
comment
Massive derp - только что понял, конечно, отпечатки на этом останавливаются - stdout закрыт   -  person Chris O'Kelly    schedule 22.01.2013


Ответы (2)


Проблема не в подпрограмме lock_stdio, просто ваш вывод перестает идти к начальному стандартному выводу и начинает идти к /dev/null.

Попробуйте открыть другой файл:

open my $debugfile, '>>', 'somefilename' or die "couldn't open debug file: $!\n";

и напишите свои операторы отладки для этого:

print $debugfile "line xxx\n";

Вы смотрели в файле журнала какие-либо сообщения об ошибках?

person ysth    schedule 22.01.2013
comment
Когда я впервые прочитал это, я почувствовал себя немного язвительно. Разве он даже не прочитал мой вопрос? черт возьми!, но это заставило меня задуматься о том, ПОЧЕМУ этот материал не отображался в файле журнала, когда сразу после него был оператор журнала. Я обнаружил, что, хотя я запускаю программу как root, при запуске она сама suid для пользователя nagios, у которого не было доступа к файлу журнала. chmod 0777ing файл журнала исправил это. довольно неловкая проблема :$ большое спасибо за мозговой удар - person Chris O'Kelly; 22.01.2013

Извините, что не поместил это в качестве комментария, но мне не хватает репутации.

Ваш подпрограмма lock_stdio отправляет все выходные данные в /dev/null, поэтому после ее вызова вы не увидите никаких выходных данных из операторов print. Изменится ли что-нибудь, если вы закомментируете этот саб?

person Ian Gralinski    schedule 22.01.2013
comment
да тоже самое заметил. Комментирование подпрограммы приводит к целому ряду новых ошибок, слишком длинных для комментария, но по существу отказано в разрешении (даже при запуске с помощью sudo) - person Chris O'Kelly; 22.01.2013