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:
Created attachment 157987 [details] Removing startpidfile and pidfile on shutdown
Oops, I mistook the steps to reproduce Steps to Reproduce: 1. ./start-slapd 2. ./stop-slapd 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) [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?
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.
*** 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 > kiki-rhel5.usersys.redhat.com 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 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
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