389-ds-base

#51079 Container image fails to start most of the time
Closed: wontfix by firstyear. Opened by robinr1.

Closed: wontfix
Reopen Issue

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
podman volume create 389ds_data
  1. Pull and run the image 389ds/dirsrv
podman run -v 389ds_data:/data -p 3636:3636 --name dirsrv 389ds/dirsrv:latest
  1. Add a database backend now to our instance (which is named localhost):
podman exec -i -t dirsrv /usr/sbin/dsconf localhost backend create --suffix dc=example,dc=com --be-name userRoot
The database was sucessfully created
  1. Initialize the instance
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
  1. Stop the instance
podman stop dirsrv
  1. Try to start the instance again
 podman start dirsrv
  1. Check if instance is effectively running
podman ps -l
  1. 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.

I'm aware of this issue and I will investigate further tomorrow.

Metadata Update from @firstyear:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None

https://pagure.io/389-ds-base/pull-request/51084#

Thanks! I tested your changed version of dscontainer and the container now seems to always start from the first try.

Metadata Update from @mreynolds:
- Issue priority set to: normal
- Issue set to the milestone: 1.4.2

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

I'll be backporting these and releasing updated containers related soon.

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1843117

Issue linked to Bugzilla: Bug 1843117

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

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)
Metadata
None
None
None
None
High
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.