Bug 245894 - Keeping pidfile may cause to fail starting ns-slapd
Keeping pidfile may cause to fail starting ns-slapd
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.0.4
All Linux
high Severity low
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
: 246647 (view as bug list)
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2007-06-27 05:34 EDT by Masato Taruishi
Modified: 2015-01-04 18:27 EST (History)
8 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:00:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Removing startpidfile and pidfile on shutdown (2.30 KB, patch)
2007-06-27 05:36 EDT, Masato Taruishi
no flags Details | Diff
remove $STARTPIDFILE as well (1.03 KB, patch)
2007-06-27 06:47 EDT, Masato Taruishi
no flags Details | Diff
process checking patch (2.48 KB, patch)
2009-01-23 11:26 EST, Martin Poole
no flags Details | Diff
Additional diffs to make fix more cross-platform (1.07 KB, patch)
2009-02-19 17:59 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Masato Taruishi 2007-06-27 05:34:36 EDT
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 05:36:09 EDT
Created attachment 157987 [details]
Removing startpidfile and pidfile on shutdown
Comment 2 Masato Taruishi 2007-06-27 06:02:12 EDT
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 06:47:38 EDT
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 06:48:30 EDT
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 10:16:07 EDT
(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 13:14:04 EDT
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 15:11:59 EDT
*** Bug 246647 has been marked as a duplicate of this bug. ***
Comment 12 Martin Poole 2009-01-23 11:26:31 EST
Created attachment 329851 [details]
process checking patch
Comment 13 Noriko Hosoi 2009-01-23 17:27:43 EST
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 17:29:34 EST
(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 12:22:02 EST
Ok, but note that this will not work on non-linux platforms (e.g. Solaris, HP-UX)
Comment 24 Nathan Kinder 2009-02-19 17:59:36 EST
Created attachment 332647 [details]
Additional diffs to make fix more cross-platform
Comment 26 Jenny Galipeau 2009-03-11 12:53:44 EDT
[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 19:00:28 EDT
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

Note You need to log in before you can comment on or make changes to this bug.