I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time?
After reboot:
jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument Jan 16 14:57:19 mail04 slapd[3285]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 14:57:19 mail04 slapd[3285]: slapd starting Jan 16 14:57:20 mail04 slapd[3285]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
After restart:
Jan 16 14:58:59 mail04 slapd[3285]: daemon: shutdown requested and initiated. Jan 16 14:58:59 mail04 slapd[3285]: slapd shutdown: waiting for 1 operations/tasks to finish Jan 16 14:58:59 mail04 slapd[3285]: slapd stopped. Jan 16 14:58:59 mail04 slapd[3402]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:58:59 mail04 slapd[3402]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:58:59 mail04 slapd[3404]: slapd starting Jan 16 14:58:59 mail04 slapd[3404]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
openldap-2.4.44-20.el7.x86_64 openldap-clients-2.4.44-20.el7.x86_64 Linux mail04 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.6.1810 (Core)
--On Wednesday, January 16, 2019 3:03 PM +0100 Marc Roos M.Roos@f1-outsourcing.eu wrote:
I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time?
After reboot:
jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument
It means:
a) You're using shared memory regions with a BDB backend b) That slapd is not cleanly shut down on a reboot. It sounds like perhaps you have a broken init system.
I would note that BDB based backends are deprecated. It's advised to use back-mdb instead.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2019 3:03 PM +0100 Marc Roos M.Roos@f1-outsourcing.eu wrote:
I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time?
After reboot:
jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument
It means:
a) You're using shared memory regions with a BDB backend b) That slapd is not cleanly shut down on a reboot. It sounds like perhaps you have a broken init system.
Must point out - this is not a fatal error, otherwise slapd would not have continued startup. The backend inits a new shared memory region and just starts up as normal, there's no reason to take any special action here.
I would note that BDB based backends are deprecated. It's advised to use back-mdb instead.
--On Wednesday, January 16, 2019 5:37 PM +0000 Howard Chu hyc@symas.com wrote:
Must point out - this is not a fatal error, otherwise slapd would not have continued startup. The backend inits a new shared memory region and just starts up as normal, there's no reason to take any special action here.
Hm, back when I used back-hdb + SHM, I have to say I didn't run into this issue with OpenLDAP unless something had cleared the shared memory region (i.e., it persisted across restarts of slapd).
So while back-hdb is clearly recovering, there still seems to me to be an issue here in that short of a server reboot, the SHM segment should remain unaffected.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 16.01.2019 um 19:03 in
Nachricht <9C84644093A248A4CD6F4653@[192.168.1.39]>:
‑‑On Wednesday, January 16, 2019 5:37 PM +0000 Howard Chu hyc@symas.com wrote:
Must point out ‑ this is not a fatal error, otherwise slapd would not have continued startup. The backend inits a new shared memory region and just starts up as normal, there's no reason to take any special action here.
Hm, back when I used back‑hdb + SHM, I have to say I didn't run into this issue with OpenLDAP unless something had cleared the shared memory region (i.e., it persisted across restarts of slapd).
So while back‑hdb is clearly recovering, there still seems to me to be an issue here in that short of a server reboot, the SHM segment should remain unaffected.
AFAIR, those memory files (e.g. __db.001) were needed especially for recovering BDB, that is when the database wasn't shut down cleanly. There seem to be two problems then: 1) Unclean shutdown of the database 2) memory files vanishing
Maybe even 1) is caused by 2)...
Regards, Ulrich
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, January 17, 2019 9:09 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Quanah Gibson-Mount quanah@symas.com schrieb am 16.01.2019 um 19:03 in
Nachricht <9C84644093A248A4CD6F4653@[192.168.1.39]>:
‑‑On Wednesday, January 16, 2019 5:37 PM +0000 Howard Chu hyc@symas.com wrote:
Must point out ‑ this is not a fatal error, otherwise slapd would not have continued startup. The backend inits a new shared memory region and just starts up as normal, there's no reason to take any special action here.
Hm, back when I used back‑hdb + SHM, I have to say I didn't run into this issue with OpenLDAP unless something had cleared the shared memory region (i.e., it persisted across restarts of slapd).
So while back‑hdb is clearly recovering, there still seems to me to be an issue here in that short of a server reboot, the SHM segment should remain unaffected.
AFAIR, those memory files (e.g. __db.001) were needed especially for recovering BDB, that is when the database wasn't shut down cleanly. There seem to be two problems then:
- Unclean shutdown of the database
- memory files vanishing
I'm talking about SHM shared memory keys. See the slapd-bdb(5)/slapd-hdb(5) man pages for the shm_key option.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Howard Chu -
Marc Roos -
Quanah Gibson-Mount -
Ulrich Windl