Bug 680305

+++ This bug was initially created as a clone of Bug #677705 +++

Description of problem: ds-logpipe.py script is failing to validate the pidfiles.
ds-logpipe.py is exiting even though the valid pid file exists. The same is true with the --serverpid=pid_no option. 


Version-Release number of selected component (if applicable): 389-ds-base.1.2.8.


How reproducible: Consistently


Steps to Reproduce:
1. Install 389-ds-base1.2.8 build on RHEL6.
2. Create an instance and run ds-logpipe.py script along with "-s" and pidfile location
3. Make sure the DS instance is running before you run the ds-logpipe.py script.
4. Run ds-logpipe.py /var/log/dirsrv/slapd-$inst/access -s /var/run/dirsrv/slapd-$inst/inst.pid -t 5
5. The script will exit even though the server is already running.

  
Actual results:

ds-logpipe.py script exits when the instance is running and pid file exists.

Expected results:

ds-logpipe.py script should check for the existence of the pid file.

Additional info:
Observed this error "Server pid [$pid_no] is not alive - exiting" when the DS stopped after running the ds-logpipe.py script.
1. ds-logpipe.py /var/log/dirsrv/slapd-$inst/access -s /var/run/dirsrv/slapd-$inst/inst.pid -t 120
2. Restart the DS instance.
3. You will get "Server pid [$pid_no] is not alive - exiting"

--- Additional comment from rmeggins on 2011-02-15 12:15:33 EST ---

I think you mean /var/run/dirsrv/slapd-$inst.pid correct?

When ds-logpipe.py prints the server pid [$pid_no] is $pid_no the correct process ID number for the running directory server?

Does the value of -t matter?  If you specify a large value of -t (the default is 60) does it work correctly?

--- Additional comment from rmeggins on 2011-02-15 12:22:28 EST ---

> 1. ds-logpipe.py /var/log/dirsrv/slapd-$inst/access -s
/var/run/dirsrv/slapd-$inst/inst.pid -t 120

Does this work?  Does the logpipe startup correctly without issuing the "Server pid is not alive - exiting" message?

> 2. Restart the DS instance.

service dirsrv restart?  Other command

> 3. You will get "Server pid [$pid_no] is not alive - exiting"

You should only see this error message if you specify --serverpid=pid on the command line, or you are using the -d debug flag.  Can you confirm that you are using the correct build?  What does
/usr/sbin/ns-slapd -v
say?  Can you attach the ds-logpipe.py script to this bug?

--- Additional comment from sramling on 2011-02-16 09:47:53 EST ---

Created attachment 479123 [details]
ds-logpipe.py python script for reference

Adding the ds-logpipe.py python script.

--- Additional comment from sramling on 2011-02-16 09:54:07 EST ---

(In reply to comment #1)
> I think you mean /var/run/dirsrv/slapd-$inst.pid correct?
> 
yes. 
> When ds-logpipe.py prints the server pid [$pid_no] is $pid_no the correct
> process ID number for the running directory server?
Yes. Its giving the right pid no.
> 
> Does the value of -t matter?  If you specify a large value of -t (the default
> is 60) does it work correctly?
No. It fails for any small or big value.

--- Additional comment from sramling on 2011-02-16 10:03:28 EST ---

(In reply to comment #2)
> > 1. ds-logpipe.py /var/log/dirsrv/slapd-$inst/access -s
> /var/run/dirsrv/slapd-$inst/inst.pid -t 120
> 
> Does this work?  Does the logpipe startup correctly without issuing the "Server
> pid is not alive - exiting" message?
> 
It waits for the specified time and exits. No error messages when the server is running..
> > 2. Restart the DS instance.
> 
> service dirsrv restart?  Other command
I tried both service dirsrv restart and /etc/init.d/dirsrv restart. The result is the same as ...Server pid [$pid_no] is not alive - exiting
> 
> > 3. You will get "Server pid [$pid_no] is not alive - exiting"
> 
> You should only see this error message if you specify --serverpid=pid on the
> command line, or you are using the -d debug flag. 
I am running with the -d debug option.
 Can you confirm that you are
> using the correct build?  What does
> /usr/sbin/ns-slapd -v
[root@test_rhel6 ~]# /usr/sbin/ns-slapd -v
389 Project
389-Directory/1.2.8.a2 B2011.046.74

> say?  Can you attach the ds-logpipe.py script to this bug?

--- Additional comment from rmeggins on 2011-02-24 17:16:03 EST ---

Created attachment 480865 [details]
0001-Bug-677705-ds-logpipe.py-script-is-failing-to-valida.patch

--- Additional comment from rmeggins on 2011-02-24 19:45:16 EST ---

To ssh://git.fedorahosted.org/git/389/ds.git
   4d96b79..e05a918  master -> master
commit e05a918b7e9563bfcbc334c524de17d0bd9ca146
Author: Rich Megginson <rmeggins>
Date:   Thu Feb 24 15:05:40 2011 -0700
Reviewed by: nkinder (Thanks!)
Branch: master
Fix Description: When reading from the access log, there may be no output for
quite some time, much longer than the timeout.  In addition, the server may
take a long time to write its serverpid file.  This meant we would open the
pipe, and the read would hang waiting to read from the server.  This would
eventually timeout and exit because we did not turn off the timer, because we
did not yet get the serverpid file.
The fix is to just assume the server is running if open_pipe succeeds, and
turn off the alarm.  If the server is running, the read from the pipe will
block until either there is some output to read, or the server exits.
I used setitimer because in the case where the server starts up and
daemonizes, it will close and reopen the pipe.  If this is not the case,
the short timer will ensure that the script exits quickly if the server is
no longer running.
NOTE: If using the script in an initconfig file, a sleep 2 will need to be
added after starting the log pipe script, for two reasons
* give the script time to create the log pipe before the server does
* when a restart is issued, this gives the running log pipe script a
chance to exit cleanly before another one is started
Platforms tested: RHEL6 x86_64
Flag Day: no
Doc impact: Yes - will need to document the required initconfig changes

To ssh://git.fedorahosted.org/git/389/ds.git
   4d56dcd..1e5fbb5  389-ds-base-1.2.8 -> 389-ds-base-1.2.8
commit 1e5fbb5b9bb97b2bbaea98c313106df92cacd457
Author: Rich Megginson <rmeggins>
Date:   Thu Feb 24 15:05:40 2011 -0700