Bug 1843155

Summary: 389ds container may fail to start due to existing process
Product: Red Hat Enterprise Linux 8 Reporter: mreynolds
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED WONTFIX QA Contact: RHDS QE <ds-qe-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: lkrispen, spichugi, tbordaz, vashirov
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-05 20:54:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description mreynolds 2020-06-02 17:45:42 UTC 
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/50989

#### Issue Description
[27/Mar/2020:01:29:27.766580532 +0000] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.2, max: TLS1.3
[27/Mar/2020:01:29:27.769148822 +0000] - INFO - Security Initialization - slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2, max: TLS1.3
[27/Mar/2020:01:29:27.770667035 +0000] - ERR - add_new_slapd_process - Unable to start slapd because it is already running as process 7
[27/Mar/2020:01:29:27.771824337 +0000] - CRIT - main - Shutting down due to possible conflicts with other slapd processes


#### Package Version and Platform
1.4.3.4 389ds container


I think that this is caused by a failure to clean /run/lock on shutdown of the container - either we are terminating the process incorrectly (which I don't think we are, the DB is clean on startup), or we aren't properly purging the lock files, expecting a new pid to exist or similar. I'll need to investigate more, as this causes spurious startup failures in my production ldap environment.
Comment 1 mreynolds 2020-06-05 20:54:14 UTC 
This does not apply to RHEL, closing...