#49854 ns-slapd should create run_dir and lock_dir directories at startup
Closed: wontfix 4 years ago by vashirov. Opened 5 years ago by mmuehlfeldrh.

Issue Description

By default, the INF file uses the following settings:
run_dir = /var/run/dirsrv
lock_dir = /var/lock/dirsrv/slapd-{instance_name}

However, both /var/run/ and /var/lock/ are links to /run, which is on tempfs on Fedora 28. This means that the "dirsrv" subdirectories will be gone if you reboot, and Directory Server fails to start.

Package Version and Platform

389-Directory/1.4.0.11.20180716git6d4caac04 B2018.197.1151

Steps to reproduce

  1. Install DS on Fedora 28 using an INF file (don't set run_dir and lock_dir). DS is running after the installation.
  2. Reboot the system.

Actual results

DS failed to start after the reboot, because the "dirsrv" subdirectory" in /var/run/ and /var/lock/ was removed, because it's on tempfs.

EMERG - main - Unable to access nsslapd-rundir: No such file or directory
EMERG - main - Ensure that user "dirsrv" has read and write permissions on /var/run/dirsrv
Error - Problem accessing the lockfile /var/lock/dirsrv/slapd-instance_name/lock

Expected results

DS should create the directories set in the two parameters on startup (not at instance creation), if the they do not exist.

Additional information

$ ls -ld /var/lock /var/run /run
lrwxrwxrwx. 1 root root 11 May 15 10:43 /var/lock -> ../run/lock
lrwxrwxrwx. 1 root root 6 May 15 10:43 /var/run -> ../run
drwxr-xr-x. 32 root root 1060 Jul 16 16:03 /run

$ mount | grep "/run"
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)


Root cause is that python installer doesn't create /etc/tmpfiles.d/dirsrv-INSTANCE.conf as old perl installer did: https://pagure.io/389-ds-base/blob/master/f/ldap/admin/src/scripts/DSCreate.pm.in#_1067

Metadata Update from @vashirov:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

5 years ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

5 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4.0

5 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: None)

5 years ago

Metadata Update from @vashirov:
- Custom field reviewstatus adjusted to ack (was: review)

5 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to review (was: ack)
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

When running tests on 1.3.x branch, they fail with the following error:

self = <lib389.paths.Paths object at 0x7fad55400240>

    def _validate_defaults(self):
        if self._defaults_cached is False:
            return False
        for k in MUST:
            if self._config.has_option(SECTION, k) is False:
>               raise KeyError('Invalid defaults.inf, missing key %s' % k)
E               KeyError: 'Invalid defaults.inf, missing key tmpfiles_d'

I've added manually this key to defaults.inf, but perhaps we can backport it to 1.3.x?

@firstyear pointed out that ns-slapd should be creating these directories at startup (not at install time via lib389). Once this is changed in 1.4.0, this issue should go away

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None (was: review)
- Issue status updated to: Open (was: Closed)

5 years ago

Metadata Update from @vashirov:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

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/2913

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.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata