Red Hat Bugzilla – Bug 245894
Keeping pidfile may cause to fail starting ns-slapd
Last modified: 2015-01-04 18:27:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20070508 Iceweasel/220.127.116.11 (Debian-18.104.22.168-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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
3. ls -l config/
Created attachment 157987 [details]
Removing startpidfile and pidfile on shutdown
Oops, I mistook the steps to reproduce
Steps to Reproduce:
3. ls -l logs/
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?
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.
(In reply to comment #3)
> Created an attachment (id=157993) 
> 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?
Sorry. I mistook the comment order so the above comment is for #4.
man rm says
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
~$ rm /nonexistent && echo ok || echo failed
rm: cannot remove `/nonexistent': No such file or directory
So I wonder why the script use both test -f and rm -f code in
*** Bug 246647 has been marked as a duplicate of this bug. ***
Created attachment 329851 [details]
process checking patch
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
(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
Sorry! I accidentally modified a wrong bug... :(
Ok, but note that this will not work on non-linux platforms (e.g. Solaris, HP-UX)
Created attachment 332647 [details]
Additional diffs to make fix more cross-platform
[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
jennyv2... not running, but pid file exists
jennyv2... attempting to start anyway [ OK ]
[root@jennyv2 admin-serv]# cat /var/run/dirsrv/slapd-jennyv2.pid
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.