Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1843117

Summary: Container image fails to start most of the time
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: rcFlags: pm-rhel: mirror+
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:53:54 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:42:15 UTC
This bug is created as a clone of upstream ticket:
https://pagure.io/389-ds-base/issue/51079

#### Issue Description
When trying to run the `docker.io/389ds/dirsrv:latest` container image non-interactively, it just exits a few seconds after being started.
Only every once in a while it stays up and works correctly.. (last try I had to start the container 28 times and the 29th time it finaly stayed up)
When starting the container with a console attached to it (`start -a`),  it seems to fail less frequent.

#### Package Version and Platform
* Platform: openSUSE MicroOS
* Container runtime: podman version 1.9.1
* Package: `docker.io/389ds/dirsrv:latest`
* 389 Directory Server Version: 1.4.4.1

#### Steps to reproduce

1. Install an openSUSE MicroOS instance
2. Create volume for data
```bash
podman volume create 389ds_data
```
3. Pull and run the image 389ds/dirsrv
```bash
podman run -v 389ds_data:/data -p 3636:3636 --name dirsrv 389ds/dirsrv:latest
```
4. Add a database backend now to our instance (which is named `localhost`):
```bash
podman exec -i -t dirsrv /usr/sbin/dsconf localhost backend create --suffix dc=example,dc=com --be-name userRoot
The database was sucessfully created
```
5. Initialize the instance
```bash
podman exec -i -t dirsrv /bin/sh -c "echo -e '\nbasedn = dc=example,dc=com' >> /data/config/container.inf"
podman exec -i -t dirsrv /usr/sbin/dsidm localhost initialise
```
6. Stop the instance
```bash
podman stop dirsrv
```
7. Try to start the instance again
```bash
 podman start dirsrv
```
8. Check if instance is effectively running
```bash
podman ps -l
```
9. Retry steps 6 to 8 if the container starts up correctly which it does from time to time here  :-)

#### Actual results
Container is not running and exited with exit code 1
```
# podman ps -l
CONTAINER ID  IMAGE                            COMMAND               CREATED       STATUS                   PORTS                   NAMES
a8b062b1b6ee  docker.io/389ds/dirsrv:latest    /usr/lib/dirsrv/d...  13 hours ago  Exited (1) 1 second ago  0.0.0.0:3636->3636/tcp  dirsrv
```
```
# podman logs dirsrv
INFO: STOPPING: Shutting down 389-ds-container ...
INFO: The 389 Directory Server Container Bootstrap
INFO: Inspired by works of: ITS, The University of Adelaide
INFO: 389 Directory Server Version: 1.4.4.1
INFO: Checking for PEM TLS files ...
INFO: Have /data/tls/server.key -> False
INFO: Have /data/tls/server.crt -> False
INFO: Have /data/tls/ca -> False
INFO: Have /data/config/pwdfile.txt -> True
INFO: Unable to configure TLS from PEM, missing a required file.
INFO: Starting 389-ds-container ...
DEBUG: Allocate local instance <class 'lib389.DirSrv'> with None
DEBUG: systemd status -> False
DEBUG: pid file -> 12
DEBUG: Pid of 12 for localhost and running
DEBUG: open(): Connecting to uri ldapi://%2Fdata%2Frun%2Fslapd-localhost.socket
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using certificate policy 1
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1
DEBUG: open(): Using root autobind ...
Traceback (most recent call last):
  File "/usr/lib/dirsrv/dscontainer", line 392, in <module>
    begin_magic()
  File "/usr/lib/dirsrv/dscontainer", line 313, in begin_magic
    status = begin_healthcheck()
  File "/usr/lib/dirsrv/dscontainer", line 344, in begin_healthcheck
    inst.open()
  File "/usr/lib/python3.8/site-packages/lib389/__init__.py", line 1065, in open
    self.sasl_interactive_bind_s("", sasl_auth, escapehatch='i am sure')
  File "/usr/lib/python3.8/site-packages/lib389/__init__.py", line 180, in inner
    return f(*args, **kwargs)
  File "/usr/lib64/python3.8/site-packages/ldap/ldapobject.py", line 465, in sasl_interactive_bind_s
    return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
  File "/usr/lib/python3.8/site-packages/lib389/__init__.py", line 180, in inner
    return f(*args, **kwargs)
  File "/usr/lib64/python3.8/site-packages/ldap/ldapobject.py", line 329, in _ldap_call
    reraise(exc_type, exc_value, exc_traceback)
  File "/usr/lib64/python3.8/site-packages/ldap/compat.py", line 44, in reraise
    raise exc_value
  File "/usr/lib64/python3.8/site-packages/ldap/ldapobject.py", line 313, in _ldap_call
    result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'errno': 111, 'info': 'Connection refused'}
INFO: STOPPING: Shutting down 389-ds-container ...
```
#### Expected results
Container stays up
```
# podman logs dirsrv
ERRO[0000] exit status 1                                
INFO: The 389 Directory Server Container Bootstrap
INFO: Inspired by works of: ITS, The University of Adelaide
INFO: 389 Directory Server Version: 1.4.4.1
INFO: Checking for PEM TLS files ...
INFO: Have /data/tls/server.key -> False
INFO: Have /data/tls/server.crt -> False
INFO: Have /data/tls/ca -> False
INFO: Have /data/config/pwdfile.txt -> True
INFO: Unable to configure TLS from PEM, missing a required file.
INFO: Starting 389-ds-container ...
DEBUG: Allocate local instance <class 'lib389.DirSrv'> with None
DEBUG: systemd status -> False
DEBUG: pid file -> 12
DEBUG: Pid of 12 is not running for localhost
DEBUG: Allocate local instance <class 'lib389.DirSrv'> with None
DEBUG: systemd status -> False
DEBUG: pid file -> 13
DEBUG: Pid of 13 for localhost and running
DEBUG: open(): Connecting to uri ldapi://%2Fdata%2Frun%2Fslapd-localhost.socket
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using certificate policy 1
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1
DEBUG: open(): Using root autobind ...
DEBUG: open(): bound as cn=Directory Manager
DEBUG: Retrieving entry with [('',)]
DEBUG: Retrieved entry [dn: 
vendorVersion: 389-Directory/1.4.4.1 B2020.114.0000

]
INFO: Applying environment configuration (if present) ...
DEBUG: Allocate local instance <class 'lib389.DirSrv'> with None
DEBUG: open(): Connecting to uri ldapi://%2Fdata%2Frun%2Fslapd-localhost.socket
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using external ca certificate /etc/dirsrv/slapd-localhost
DEBUG: Using certificate policy 1
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1
DEBUG: open(): Using root autobind ...
DEBUG: open(): bound as cn=Directory Manager
DEBUG: Retrieving entry with [('',)]
DEBUG: Retrieved entry [dn: 
vendorVersion: 389-Directory/1.4.4.1 B2020.114.0000

]
INFO: 389-ds-container started.
```

Comment 2 mreynolds 2020-06-05 20:53:54 UTC
This bug does not apply to RHEL, closing