Bug 245894

Summary: Keeping pidfile may cause to fail starting ns-slapd
Product: [Retired] 389 Reporter: Masato Taruishi <taruishi>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: high    
Version: 1.0.4CC: benl, djuran, jgalipea, mpoole, nhosoi, rmeggins, takamiya, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:00:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
Removing startpidfile and pidfile on shutdown
none
remove $STARTPIDFILE as well
none
process checking patch
none
Additional diffs to make fix more cross-platform none

Description Masato Taruishi 2007-06-27 09:34:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070508 Iceweasel/2.0.0.4 (Debian-2.0.0.4-1)

Description of problem:
In the fedora-ds ldapserver implementation, there is a code to
write startpidfile and pidfile but it doesn't remove these
files in shutdown. It may keep the previous pid number in these
files and cause to point another process even if ns-slapd
terminates normally. 

I attached the patch to add the remove code in this report,
but it's not for WIN32 because I have no idea about windows
implementation.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. ./start-slapd
2. ./stop-slapd
3. ls -l config/

Actual Results:


Expected Results:


Additional info:

Comment 1 Masato Taruishi 2007-06-27 09:36:09 UTC
Created attachment 157987 [details]
Removing startpidfile and pidfile on shutdown

Comment 2 Masato Taruishi 2007-06-27 10:02:12 UTC
Oops, I mistook the steps to reproduce

Steps to Reproduce:
1. ./start-slapd
2. ./stop-slapd
3. ls -l logs/


Comment 3 Masato Taruishi 2007-06-27 10:47:38 UTC
Created attachment 157993 [details]
remove $STARTPIDFILE as well

I guess rm -f $PIDFILE $STARTPIDFILE is enough for linux, but
the script uses test -f for the existence checking.
Is there any reason for it?

Comment 4 Masato Taruishi 2007-06-27 10:48:30 UTC
According to more investigation, ./stop-slapd removes only PIDFILE.
So if you use stop-slapd, STARTPIDFILE would be kept in the directory.

./start-slapd checks for the existence of STARTPIDFILE which may
cause the problem. So ./stop-slapd should remove STARTPIDFILE as well.

Anyway, the task which creates pidfile is ns-slapd and the task
which remove pidfile is the script. I think it should be handled
in the same tier. Otherwise, throwing SIGTERM to ns-slapd directly
causes this problem again.

Comment 5 Rich Megginson 2007-06-27 14:16:07 UTC
(In reply to comment #3)
> Created an attachment (id=157993) [edit]
> remove $STARTPIDFILE as well
> 
> I guess rm -f $PIDFILE $STARTPIDFILE is enough for linux, but
> the script uses test -f for the existence checking.
> Is there any reason for it?

I'm not sure what you mean?


Comment 6 Masato Taruishi 2007-06-28 17:14:04 UTC
Sorry. I mistook the comment order so the above comment is for #4.

man rm says

       -f, --force
              ignore nonexistent files, never prompt

which means you don't have to put 

 if test -f "$PIDFILE"; then

if you use rm -f "$PIDFILE"

~$ rm -f /nonexistent && echo ok
ok
~$ rm /nonexistent && echo ok || echo failed
rm: cannot remove `/nonexistent': No such file or directory
failed

So I wonder why the script use both test -f and rm -f code in
template-stop-slapd.in.

Comment 7 Noriko Hosoi 2007-07-03 19:11:59 UTC
*** Bug 246647 has been marked as a duplicate of this bug. ***

Comment 12 Martin Poole 2009-01-23 16:26:31 UTC
Created attachment 329851 [details]
process checking patch

Comment 13 Noriko Hosoi 2009-01-23 22:27:43 UTC
Test Name 	                 PASS
Long Duration Pwdstorage run 	 100% (1/1) 
Subject: DS8.1 Linux_RHEL5_x86_64-64 Long duration test report - 100% passed on kiki-rhel5.usersys.redhat.com

Comment 14 Noriko Hosoi 2009-01-23 22:29:34 UTC
(In reply to comment #13)
> Test Name                   PASS
> Long Duration Pwdstorage run   100% (1/1) 
> Subject: DS8.1 Linux_RHEL5_x86_64-64 Long duration test report - 100% passed on
> kiki-rhel5.usersys.redhat.com

Sorry!  I accidentally modified a wrong bug... :(

Comment 18 Rich Megginson 2009-02-17 17:22:02 UTC
Ok, but note that this will not work on non-linux platforms (e.g. Solaris, HP-UX)

Comment 24 Nathan Kinder 2009-02-19 22:59:36 UTC
Created attachment 332647 [details]
Additional diffs to make fix more cross-platform

Comment 26 Jenny Severance 2009-03-11 16:53:44 UTC
[root@jennyv2 admin-serv]# ps -ef | egrep 16855
root     16855 16827  0 12:54 pts/3    00:00:00 vim bogus
root     16859 15232  0 12:54 pts/1    00:00:00 egrep 16855

[root@jennyv2 admin-serv]# service dirsrv stop
Shutting down dirsrv: 
    jennyv2...                                             [  OK  ]

[root@jennyv2 admin-serv]# echo 16855 > /var/run/dirsrv/slapd-jennyv2.pid

[root@jennyv2 admin-serv]# echo 16855 > /var/run/dirsrv/slapd-jennyv2.startpid 

[root@jennyv2 admin-serv]# service dirsrv start
Starting dirsrv: 
    jennyv2... not running, but pid file exists
    jennyv2... attempting to start anyway                  [  OK  ]


[root@jennyv2 admin-serv]# cat /var/run/dirsrv/slapd-jennyv2.pid 
16924

Comment 28 Chandrasekar Kannan 2009-04-29 23:00:28 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html