Created attachment 152838 [details]
Patch to correct the "/etc/rc.d/slapd" file
The default "slapd" file in "/usr/local/etc/rc.d" is run before the "/etc/rc.d/clearvar" or "/etc/rc.d/cleartmp" files are initiated. This causes the files
"SEMDMDBr?Nu;oi>KeQ" and "SEMDMDBw?Nu;oi>KeQ" which are created in the "/tmp" directory to be deleted. This in turn causes "slapcat" to fail when run.
I modified the "/usr/local/etc/rc.d/slapd" file to correct this problem. The patch is attached.
Auto-assigned to maintainer delphij@FreeBSD.org
IMHO the proposed patch is wrong, as slapd must start early to support anything that looks up the directory.
Brooks -- In r153028, the commit message say "Brooks pointed out a case where tmp needs to be run after mountcritremote, so force it the other way instead.", but didn't mention the case, would you please elaborate that? IMO /tmp must be mounted very early because POSIX semaphores depends on it to work, and by deferring it after mountcritremote, it's limiting the applications that uses POSIX semaphores as /tmp could potentially be remounted, and that would cause all kinds of problems.
While I can fully appreciate Xin LI's thoughts on this, there must be a way to make everybody happy. Maybe there is someway to make it an option as to when "slapd" is started. I think that we can agree that having files deleted that were initially created when "slapd" was called is not an ideal situation. Especially when it results in failures of other programs. The solution I came up with was suggested to me by other users who said that they were having the same problems I was. Therefore, I do not think this is an isolated incident.
(In reply to Gerard Seibert from comment #3)
Well, the right fix IMHO is to make 'tmp' and 'cleartmp' start earlier, we are not guaranteed that no other early daemons that does not make use of POSIX semaphore and they would all be broken if cleartmp is enabled.
Is anyone going to try and actually fix this problem or is it going to be simply swept aside? At the very least, if a fix is not forthcoming, then a warning should be included with the installation that the files I mentioned will be deleted and "slapcat" and possibly other applications will fail. At least a new user will not waste time trying to debug a known situation.
The fix that I described earlier was given to me by other users who had experienced this same problem. Mentioning it along with the known problem might also prove helpful.
Every time openldap is updated, I experience the same problem.
In any case, if no one is going to fix this problem, then this report should be closed.
If no one is going to come up with a suitable solution to this annoying problem, then this "report" should be closed. I do find it hard to believe that a solution, other than editing the "slapd" file after every update is not doable. Perhaps a warning that the "slapd" file is going to be overwritten when updating might be of limited help.
Is this still relevant?
(In reply to w.schwarzenfeld from comment #7)
Yes, I still have to update /usr/local/etc/rc.d/slapd after every update and add "cleartmp" to the "REQUIRE" list. I agree with Xin that it is probably better to make "cleartmp" start earlier.
After r519256 the files should no longer get created.
A commit references this bug:
Date: Sat Dec 7 23:31:48 UTC 2019
New revision: 519256
net/openldap24-server: back_mdb: use robust mutexes.