Mgr Peter Tuharsky <[EMAIL PROTECTED]> writes: >> This generally indicates a permission issue. If, for example, you run >> slapd as root and then later try to run it as another user, or if you >> change what user you're running slapd as, you need to change the >> ownership of all of the files in /var/lib/ldap to match the user you're >> running slapd as.
> It's strange, yes, some files are created by openldap user, while others > are root's. However, I don't know, why should slapd have any problems > with root's files. If it's running as a non-root user, it will not be able to write to root-owned files, which depending on what files are involved will be reported as database corruption deep inside the BerkeleyDB libraries. If it's running as a root user, it shouldn't matter. > We run slapd by custom script (because of bug 416272), that contains > just /usr/bin/slapd, thus it should run as root, shouldn't? Well, I don't know what your custom script does. Could you mail it to the bug report? Also, I'd love to fix 416272, but it contains essentially no information and the init script works fine for everyone else, so right now there's really nothing we can do about it. My guess is that your problems are caused by not using the regular init script and the best solution would be to go back and figure out what the *real* problem in 416272 was and fix it. > And we met the problems also when running slapd manually from root's > console. One thing that would be very helpful, both here and with 416272, is actual error messages. It's very hard to debug things without the specific error messages (and in particular, running slapd -d 1 may be necessary to get the detailed errors). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
