Bug 1360447 – nsslapd-workingdir is empty when ns-slapd is started by systemd

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 1360447 - nsslapd-workingdir is empty when ns-slapd is started by systemd

Summary:	nsslapd-workingdir is empty when ns-slapd is started by systemd

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	389-ds-base (Show other bugs)
Sub Component:
Version:	7.3
Hardware:	Unspecified Unspecified

Priority	urgent Severity urgent
Target Milestone:	rc
Target Release:	---
Assigned To:	Noriko Hosoi
QA Contact:	Viktor Ashirov
Docs Contact:	Petr Bokoc

URL:
Whiteboard:
Keywords:	Regression, TestBlocker

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2016-07-26 14:44 EDT by Viktor Ashirov
Modified:	2016-11-03 16:44 EDT (History)
CC List:	5 users (show)

See Also:
Fixed In Version:	389-ds-base-1.3.5.10-6.el7
Doc Type:	Bug Fix
Doc Text:	nsslapd now correctly sets its working directory A regression introduced in an earlier bug fix caused nsslapd to skip setting its working directory (the `nsslapd-workingdir` attribute) by default when it was started by systemd. This bug has been fixed and the working directory is being set during startup again.
Story Points:	---
Clone Of:
Environment:
Last Closed:	2016-11-03 16:44:29 EDT
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2016:2594	normal	SHIPPED_LIVE	Moderate: 389-ds-base security, bug fix, and enhancement update	2016-11-03 08:11:08 EDT

Groups: None (edit)

Description Viktor Ashirov 2016-07-26 14:44:21 EDT

Description of problem:
nsslapd-workingdir is empty when ns-slapd is started by systemd. When ns-slapd is started manually, the attribute has value.

Version-Release number of selected component (if applicable):
389-ds-base-1.3.5.10-5.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. start-dirsrv
2. ldapsearch -D "cn=Directory manager" -w Secret123 -b cn=config | grep ^nsslapd-workingdir


Actual results:
ldapsearch returns empty attribute
ldapsearch -D "cn=Directory manager" -w Secret123 -b cn=config | grep ^nsslapd-workingdir
nsslapd-workingdir:

Expected results:
ldapsearch -D "cn=Directory manager" -w Secret123 -b cn=config | grep ^nsslapd-workingdir
nsslapd-workingdir: /var/log/dirsrv/slapd-qeos-34

Additional info:
Bug was found by Simon Pichugin

Comment 3 Noriko Hosoi 2016-07-26 20:29:35 EDT

Upstream ticket:
https://fedorahosted.org/389/ticket/48939

Comment 5 Simon Pichugin 2016-08-22 04:20:49 EDT

Build tested:
389-ds-base-1.3.5.10-8.el7.x86_64

Verification steps:
1. Install an instance
2. ldapsearch -D "cn=Directory manager" -w Secret123 -b cn=config | grep ^nsslapd-workingdir

Result:
nsslapd-workingdir: /var/log/dirsrv/slapd-standalone

Marking as verified.

Comment 7 errata-xmlrpc 2016-11-03 16:44:29 EDT

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html

Note You need to log in before you can comment on or make changes to this bug.