Side note - there are new compiler warnings around the bdb code:

ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c: In function 'bdb_delete_database_ex':
ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:4223:22: warning: variable 'priv' set but not used [-Wunused-but-set-variable]
     dblayer_private *priv = NULL;
                      ^~~~
ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c: In function 'bdb_get_aux_id2entry_ext':
ldap/servers/slapd/back-ldbm/db-bdb/bdb_layer.c:1926:8: warning: 'priv' may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (priv) {
        ^

How are you setting the home directory. If I edit dse.ldif and add
nsslapd-db-home-directory : /dev/shm
to the cn=bdb,cn=config,..... entry it puts
__db, DBVERSION and log. to /dev/shm and leaves the userRoot db where it is.

About the warnings I don't see them, the code has not change, maybe you are using a newer gcc ?

How are you setting the home directory. If I edit dse.ldif and add
nsslapd-db-home-directory : /dev/shm

I was testing with my patch that auto-creates everything for you (selinux needs to be disabled)
Try this patch and see if the behavior changes. This patch automatically creates /dev/shm/dirsrv/slapd-localhost when you create a new instance

You will need to build the rpm for this be applied correctly (make -f rpm.mk rpms)

I hope it's not an issue with libdb on RHEL 8: libdb-5.3.28-37.el8.x86_64

to the cn=bdb,cn=config,..... entry it puts
__db, DBVERSION and log. to /dev/shm and leaves the userRoot db where it is.
About the warnings I don't see them, the code has not change, maybe you are using a newer gcc ?

This was on rhel 8.1:

gcc-8.3.1-4.5.el8.x86_64

Hmm I just noticed my patch uses this defualt for db home:

• 'db_home_dir' : ('cn=config,cn=ldbm database,cn=plugins,cn=config', 'nsslapd-db-home-directory'),

This is NOT the bdb config entry, yet it seems to be breaking things... I will try with it set to the bdb config entry, but either way it is misbehaving...

But it was still auto setting/migrating the db_home attribute attribute to the bdb config entry. Maybe that's where things are getting messed up?

Well I'm building a new rpm with the proper bdb config entry, so I should now soon if that behaves differently...

Sorry on RHEL 8.1 it still puts everything under db-home-dir regardless of the config dn :-(

thanks for the hints, I will work on it

I have reproduced the behavior. The reason that it seems to work for me was that for existing instances the instance-dir is already set and when setting db-home they are not affected.

My test scenario is:
- create an instance
- stop it and set nsslapd-db-home-directory
- create a new backend.

This scenario is fixed with PR: https://pagure.io/389-ds-base/pull-request/50770

A fresh install is still not working correctly:

[27/Feb/2020:10:51:57.285176856 -0500] - ERR - libdb - BDB2521 /var/lib/dirsrv/slapd-localhost/db/log.0000000001: log file open failed: No such file or directory
[27/Feb/2020:10:51:57.307862503 -0500] - ERR - libdb - BDB0061 PANIC: No such file or directory

# ls -laZ /dev/shm/dirsrv/slapd-localhost/
total 8484
drwxrwx---. 3 dirsrv dirsrv unconfined_u:object_r:dirsrv_tmpfs_t:s0      160 Feb 27 10:51 .
drwxr-xr-x. 3 root   root   system_u:object_r:dirsrv_tmpfs_t:s0           60 Feb 27 10:51 ..
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0      1163264 Feb 27 10:51 __db.001
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0      6184960 Feb 27 10:51 __db.002
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0      1926360 Feb 27 10:51 __db.003
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0           51 Feb 27 10:51 DBVERSION
-rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0     10485760 Feb 27 10:51 log.0000000001
drwx------. 2 dirsrv dirsrv system_u:object_r:dirsrv_tmpfs_t:s0          260 Feb 27 10:51 userroot

The userroot directory should not be in home dir, but the config entry is using the home directory for the db directory. Also the transaction logs are incorrectly in the home directory

Here is the config after a fresh install:

dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config
nsslapd-directory: /dev/shm/dirsrv/slapd-localhost/userroot   <-- WRONG

dn: cn=bdb,cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-db-logdirectory: /var/lib/dirsrv/slapd-localhost/db
nsslapd-db-home-directory: /dev/shm/dirsrv/slapd-localhost

So we still have issues here when using db-home-dir :-(

Here is the currently patch I am using to reproduce the problem. So after a fresh install I see the issue in the comment above:

Trying to reproduce, but don't get over this error:

 [04/Mar/2020:14:49:56.620742564 +0100] - ERR - bdb_version_write - Could not open file "%s" for writing Netscape Portable Runtime %d (%s)
  - /dev/shm/dirsrv/slapd-mark3/DBVERSION[04/Mar/2020:14:49:56.627170148 +0100] - WARN - spal_meminfo_get - cgroups v1 or v2 unable to be read - may not be on this platform ...
 [04/Mar/2020:14:49:56.633597542 +0100] - ERR - libdb - /dev/shm/dirsrv/slapd-mark3/__db.001: Permission denied
 [04/Mar/2020:14:49:56.639897506 +0100] - CRIT - bdb_start - Opening database environment (/dev/shm/dirsrv/slapd-mark3) failed. err=13: Permission denied
 [04/Mar/2020:14:49:56.646291234 +0100] - ERR - ldbm_back_start - Failed to init database, err=13 Permission denied

Trying to reproduce, but don't get over this error:
[04/Mar/2020:14:49:56.620742564 +0100] - ERR - bdb_version_write - Could not open file "%s" for writing Netscape Portable Runtime %d (%s)

This looks like a logging bug :-)

• /dev/shm/dirsrv/slapd-mark3/DBVERSION[04/Mar/2020:14:49:56.627170148 +0100] - WARN - spal_meminfo_get - cgroups v1 or v2 unable to be read - may not be on this platform ...
  [04/Mar/2020:14:49:56.633597542 +0100] - ERR - libdb - /dev/shm/dirsrv/slapd-mark3/__db.001: Permission denied
  [04/Mar/2020:14:49:56.639897506 +0100] - CRIT - bdb_start - Opening database environment (/dev/shm/dirsrv/slapd-mark3) failed. err=13: Permission denied
  [04/Mar/2020:14:49:56.646291234 +0100] - ERR - ldbm_back_start - Failed to init database, err=13 Permission denied

This is SElinux causing the permissions issue. Which is why I wanted you to test the rpm, and you need to test it on F31 or higher (or RHEL 8) to get the current policy. Disabling selinux should work though, did you try that?

If you are still having issues I will setup a RHEL 8 beaker box for you.

I am testing with rpms, but on F28 :-(

@lkrispen Sorry to jump into the thread for a minor unrelated question, I was surprise to see

[04/Mar/2020:14:49:56.627170148 +0100] - WARN - spal_meminfo_get - cgroups v1 or v2 unable to be read - may not be on this platform ...

Would you confirm that on F28, there is no '/sys/fs/cgroup/memory' nor entry with head '0::' in /proc/self/cgroup ?

/proc/self/cgroup is empty

but

  ls -l /sys/fs/cgroup/memory/
 total 0
 -rw-r--r--.  1 root root 0 Mar  4 15:33 cgroup.clone_children
 --w--w--w-.  1 root root 0 Mar  4 15:33 cgroup.event_control
 -rw-r--r--.  1 root root 0 Mar  4 15:33 cgroup.procs
 -r--r--r--.  1 root root 0 Mar  4 15:33 cgroup.sane_behavior
 drwxr-xr-x.  2 root root 0 Mar  4 14:09 machine.slice
 -rw-r--r--.  1 root root 0 Mar  4 15:33 memory.failcnt
 --w-------.  1 root root 0 Mar  4 15:33 memory.force_empty
 ......

Thanks @lkrispen, so F28 is on cgroup V1 but likely due to SElinux, DS failed to detect that. What I am missing is that on SElinux enforced platform we should always see this message.

This was fixed in https://pagure.io/389-ds-base/pull-request/50770

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3810

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.