ando@sys-net.it wrote:
The difference is that if the monitor database comes first, it's already open when the bdb tries to register its custom monitor stuff. So it can barf out when the addition fails because of no enough permissions.
If it comes later, back-bdb's custom monitor stuff ends up in the limbo, which is then flushed when the monitor database starts up. At this point, a failure in flushing the limbo is not considered critical.
I see two/three solutions:
allow databases to fail monitor info registration without aborting
make startup fail also when limbo flushing fails
let the monitor database have a default rootdn.
I'm not oriented towards any of the above, yet.
I think the point is: if one explicitly requests monitoring support (by default on) in back-bdb, then it must either succeed or slapd should not start.
If one does not explicitly request it, giving up monitoring with a warning should be fine.
This is complicated by the need to support run-time configuration: in fact, if monitoring is explicitly requested but it cannot be registered, the creation of that database should fail, but the daemon should not stop.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------