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.
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.
```