[Apologies for the lack of additional information on the bug report, but slapd is only set up in a VM] Hi, I have been trying to debug some problems so I use -d quite often. If i forget to /etc/init.d/slapd stop before trying this then slapd -d from the command line fails as you would expect. Then when I try and stop the daemon with /etc/init.d/slapd stop it looks ok, but the daemon is left running, and must be killed, which is not so good. To reproduce /etc/init.d/slapd start slapd -d 1 (fails) /etc/init.d/slapd stop (nothing seems amiss) slapd -d 1 (fails again) /etc/init.d/slapd stop . . . Doesn't stop the daemon. Thanks, James
James Westby wrote: I can't reproduce it here, just tried your flow to reproduce but that didn't work: /etc/init.d/slapd start (works) slapd -d 1 (fails, because port is in use) /etc/init.d/slapd stop (works, check pstree -u if slapd is running) slapd -d 1 (works, because slapd is stopped) /etc/init.d/slapd stop (works also, the 'slapd -d 1' is killed) If you want to run a second instance of slapd, you can better try to create another configuration file and set it up so that it doesn't interfere with the other one. But why do you want that ? slapd can run with multiple directories ? Regards, Matthijs Mohlmann
Hmmm. I can do it at will. Maybe i should have been more precise, sorry, let's try again. Attached is my slapd.conf if that makes any difference. I think it's because I try and start the second on a different port. slapd -d 1 -h ldaps://0.0.0.0:80/ (fails as db is in use) /etc/init.d/slapd stop (fails, pstree -u shows it running) Attached is a trace of the problem. I don't want a second instance, I just temporarily want a debugging instance of slapd so I can grab a trace for other bug reports. I could set up a second config etc. but this is a test system so I can pull the main one down with no worries. I realise this might not be a very common case, hence severity minor. The second thing is that I want the debugging instance on port 80 so that I can bypass a firewall that I'm too lazy to open up a port in. I'm not running a webserver. Again apologies for the poor first report, hopefully this one is better. James
Sorry aboutu the delay in replying to this (over two year old) bug. James Westby <jw+debian@jameswestby.net> writes: What happened is that when you started the second slapd, it overwrote the PID file for the first slapd, at which point the init script no longer knows what PID slapd has and will try to stop the debugging version. I don't think this is a problem that can really be fixed. You have to go to some effort to overwrite the PID file, as you found out, and the init script really relies on the PID file being correct. My inclination is to close this bug as something we can't really fix, although let me know if you object.
Closing bug, running a second instance is not supported. Regards, Matthijs Mohlmann
reopen 375067 thanks Supporting running a second instance is a separate question from allowing an attempt to start a second instance to steal the pid file of the already-running server. This is a bug.
LDAP server you need also a separate slapd.conf file. In the configuration the pidfile is defined. So if someone wants to setup a new instance then you need also a new configuration file. And if the user then defines the same pidfile that would be an user configuration error or am I wrong here? So first of all, running a second instance is in my opinion no problem at all. Second: stealing a pidfile is not a failure on part of slapd but a configuration error. Regards, Matthijs Mohlmann
Please reread the original report. He didn't *want* two instances of the LDAP server; he was just trying to debug the server, and in the process it broke the init script's ability to find the process because he forgot to stop the service first. No, it's a bug in the interaction of slapd and the (non-upstream) init script. If nothing else, it's also quite fixable with upstart, which may become the default init system in Debian fairly soon; so unlike Russ, I don't think this should be closed as "difficult to fix".