[suggest] nagios-3.2.1-5.el4.rf.i386.rpm pid path problem

[Mark D. Nagel]

The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark

thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.


+C

[Christoph Maser]

Post by Christoph Maser

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.
+C

Hi Mark

I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

+C

[Mark D. Nagel]

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
is still passed to the reload function (but nowhere else):

reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}
Regards,
Mark

Hi Mark

thanks for pointing that out I simply overlooked it. Update is underway.

Chris

[Dag Wieers]

Post by Christoph Maser

Post by Mark D. Nagel

Post by Christoph Maser
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

thanks for pointing that out I simply overlooked it. Update is underway.

Oh my, and when the same was reported to me I though subversion had an
important bug on my system since the patch clearly removed the "-p
${pidfile}", but a grep clearly showed it was still there on my disk and
subversion reported it was the latest revision.

Overlooking the fact that it was on a different line, and a slightly
different commandline. Damned :-)

At least I can restore my trust in subversion a little bit now... Sigh.

[Dag Wieers]

Post by Christoph Maser

Post by Mark D. Nagel

Post by Christoph Maser
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

thanks for pointing that out I simply overlooked it. Update is underway.

Oh my, and when the same was reported to me I though subversion had an
important bug on my system since the patch clearly removed the "-p
${pidfile}", but a grep clearly showed it was still there on my disk and
subversion reported it was the latest revision.

Overlooking the fact that it was on a different line, and a slightly
different commandline. Damned :-)

At least I can restore my trust in subversion a little bit now... Sigh.

[Dag Wieers]

Post by Christoph Maser

Post by Mark D. Nagel

Post by Christoph Maser
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

thanks for pointing that out I simply overlooked it. Update is underway.

Oh my, and when the same was reported to me I though subversion had an
important bug on my system since the patch clearly removed the "-p
${pidfile}", but a grep clearly showed it was still there on my disk and
subversion reported it was the latest revision.

Overlooking the fact that it was on a different line, and a slightly
different commandline. Damned :-)

At least I can restore my trust in subversion a little bit now... Sigh.

[Dag Wieers]

Post by Christoph Maser

Post by Mark D. Nagel

Post by Christoph Maser
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

thanks for pointing that out I simply overlooked it. Update is underway.

Oh my, and when the same was reported to me I though subversion had an
important bug on my system since the patch clearly removed the "-p
${pidfile}", but a grep clearly showed it was still there on my disk and
subversion reported it was the latest revision.

Overlooking the fact that it was on a different line, and a slightly
different commandline. Damned :-)

At least I can restore my trust in subversion a little bit now... Sigh.

[Dag Wieers]

Post by Christoph Maser

Post by Mark D. Nagel

Post by Christoph Maser
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

thanks for pointing that out I simply overlooked it. Update is underway.

Oh my, and when the same was reported to me I though subversion had an
important bug on my system since the patch clearly removed the "-p
${pidfile}", but a grep clearly showed it was still there on my disk and
subversion reported it was the latest revision.

Overlooking the fact that it was on a different line, and a slightly
different commandline. Damned :-)

At least I can restore my trust in subversion a little bit now... Sigh.

[Christoph Maser]

Post by Mark D. Nagel

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}
Regards,
Mark

Hi Mark

thanks for pointing that out I simply overlooked it. Update is underway.

Chris

[Christoph Maser]

Post by Mark D. Nagel

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}
Regards,
Mark

Hi Mark

thanks for pointing that out I simply overlooked it. Update is underway.

Chris

[Christoph Maser]

Post by Mark D. Nagel

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}
Regards,
Mark

Hi Mark

thanks for pointing that out I simply overlooked it. Update is underway.

Chris

[Christoph Maser]

Post by Mark D. Nagel

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}
Regards,
Mark

Hi Mark

thanks for pointing that out I simply overlooked it. Update is underway.

Chris

[Mark D. Nagel]

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
is still passed to the reload function (but nowhere else):

reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

Regards,
Mark

[Mark D. Nagel]

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
is still passed to the reload function (but nowhere else):

reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

Regards,
Mark

[Mark D. Nagel]

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
is still passed to the reload function (but nowhere else):

reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

Regards,
Mark

[Mark D. Nagel]

Post by Christoph Maser
Hi Mark
I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

I just finally updated to the latest RPM today to test because we ran
into a DST bug in 3.2.0 yesterday. It looks like the EL5-only -p option
is still passed to the reload function (but nowhere else):

reload() {
echo -n $"Reloading $prog: "
killproc -p ${pidfile} $exec -HUP
RETVAL=$?
echo
}

Regards,
Mark

[Christoph Maser]

Post by Christoph Maser

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.
+C

Hi Mark

I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

+C

[Christoph Maser]

Post by Christoph Maser

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.
+C

Hi Mark

I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

+C

[Christoph Maser]

Post by Christoph Maser

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.
+C

Hi Mark

I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

+C

[Christoph Maser]

Post by Christoph Maser

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.
+C

Hi Mark

I submitted an update dropping the pid-file parameter when calling
killproc. This works correctly on el4 and el5 at least in my tests.

+C

[David Hrbáč]

Post by Christoph Maser
Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.

Chris,
Well, so I'm not so fuzzy, I mean on pid complaining yesterday :o)
DH

[David Hrbáč]

Post by Christoph Maser
Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.

Chris,
Well, so I'm not so fuzzy, I mean on pid complaining yesterday :o)
DH

[David Hrbáč]

Post by Christoph Maser
Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.

Chris,
Well, so I'm not so fuzzy, I mean on pid complaining yesterday :o)
DH

[David Hrbáč]

Post by Christoph Maser
Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.

Chris,
Well, so I'm not so fuzzy, I mean on pid complaining yesterday :o)
DH

[David Hrbáč]

Post by Christoph Maser
Mark
thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.

Chris,
Well, so I'm not so fuzzy, I mean on pid complaining yesterday :o)
DH

[Mark D. Nagel]

The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark

thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.


+C

[Mark D. Nagel]

The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark

thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.


+C

[Mark D. Nagel]

The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark

thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.


+C

[Mark D. Nagel]

The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.

Regards,
Mark

[Christoph Maser]

Post by Mark D. Nagel
The path to nagios.pid was changed from /var/run/nagios.pid to
/var/nagios/nagios.pid between the 3.2.0 and 3.2.1 RPM release. This
would be fine if the killproc function from /etc/init.d/functions in EL4
supported the -p flag as used in the init script, but this is not
available in EL4. Thus, using the init script to restart or stop in EL4
is broken, generating all manner of errors due to invalid calls to pidof
and such. Seems like the simplest fix would be to revert to the 3.2.0
init script for EL4, which works just fine, or keep the new script but
place the pid file back into /var/run for EL4. The alternative would be
to roll your own replacement for killproc that behaves like the EL5
killproc.
Regards,
Mark

Mark

thank you for reporting. The reason why i switched the pid location is
that at startup i now use --user in the daemon-function. So now the pid
file must be in a location where nagios can create it. I did change the
startup call to use --daemon to make things more robust since there is
some error in nagios drop-privilege code.
I will rethink the whole thing.


+C