Startup issue with 1.2.3

[danwelcome]

I am having an issue on startup with the latest version (1.2.3). This issue doesn't happen for me on 1.2.2. Here are the logs:

2019-01-27T00:51:55.556899266Z Start OpenLDAP...
2019-01-27T00:51:55.610210985Z Waiting for OpenLDAP to start...
2019-01-27T00:51:55.614614565Z Add TLS config...
2019-01-27T00:51:55.702928252Z Disable replication config...
2019-01-27T00:51:55.849956679Z *** /container/run/startup/slapd failed with status 34
2019-01-27T00:51:55.850142842Z
2019-01-27T00:51:55.850192678Z *** Killing all processes...
2019-01-27T00:52:48.921313505Z *** CONTAINER_LOG_LEVEL = 3 (info)
2019-01-27T00:52:48.922151599Z *** Search service in CONTAINER_SERVICE_DIR = /container/service :
2019-01-27T00:52:48.922271110Z *** link /container/service/:ssl-tools/startup.sh to /container/run/startup/:ssl-tools
2019-01-27T00:52:48.922338966Z *** failed to link /container/service/:ssl-tools/startup.sh to /container/run/startup/:ssl-tools: [Errno 17] File exists
2019-01-27T00:52:48.922410621Z *** link /container/service/slapd/startup.sh to /container/run/startup/slapd
2019-01-27T00:52:48.922474593Z *** failed to link /container/service/slapd/startup.sh to /container/run/startup/slapd: [Errno 17] File exists
2019-01-27T00:52:48.922534176Z *** link /container/service/slapd/process.sh to /container/run/process/slapd/run
2019-01-27T00:52:48.922591009Z *** directory /container/run/process/slapd already exists
2019-01-27T00:52:48.922645501Z *** failed to link /container/service/slapd/process.sh to /container/run/process/slapd/run : [Errno 17] File exists
2019-01-27T00:52:48.922704333Z *** Set environment for startup files
2019-01-27T00:52:48.926415503Z *** Environment files will be proccessed in this order :
2019-01-27T00:52:48.926543956Z Caution: previously defined variables will not be overriden.
2019-01-27T00:52:48.926616165Z /container/environment/99-default/default.startup.yaml
2019-01-27T00:52:48.926685192Z /container/environment/99-default/default.yaml
2019-01-27T00:52:48.926754169Z
2019-01-27T00:52:48.926813217Z To see how this files are processed and environment variables values,
2019-01-27T00:52:48.927014308Z run this container with '--loglevel debug'
2019-01-27T00:52:48.949824664Z *** Running /container/run/startup/:ssl-tools...
2019-01-27T00:52:48.963657410Z *** Running /container/run/startup/slapd...

[tcuje]

Same issue here. Downgrade to version 1.2.2 as workaround solved the issue.

[obourdon]

@tcuje @danwelcome works like a charm for me on MacOSX
may be giving the output of docker version, giving the full command line parameters and env variables you are using and run the container with additional --loglevel debug could help

[trijenhout]

updated to day and now i need to downgrade to...some where to look out for any testing needed??? i wil look into --loglevel debug.... later... grts (ps opensuse leap15 docker 1.38...)

[danwelcome]

I am running Docker on a Synology NAS. The docker --version command outputs the following:

Docker version 17.05.0-ce, build 9f07f0e-synology

I use openldap with docker compose. My config is configured like this (variables are in a .env file, but should't really matter):

openldap:
    image: osixia/openldap:latest
    networks:
      - backend
    volumes:
      - "${OPENLDAP_CONFIG}/db:/var/lib/ldap"
      - "${OPENLDAP_CONFIG}/slapd.d:/etc/ldap/slapd.d"
    restart: always
    environment:
      LDAP_ORGANISATION: ${SERVER_NAME}
      LDAP_DOMAIN: ${SERVER_NAME}
      LDAP_ADMIN_PASSWORD: secret

log-level doesn't appear to be supported with my version of docker-compose:

sh-4.3# docker-compose --log-level DEBUG start openldap
Define and run multi-container applications with Docker.

Usage:
  docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...]
  docker-compose -h|--help

Options:
  -f, --file FILE             Specify an alternate compose file (default: docker-compose.yml)
  -p, --project-name NAME     Specify an alternate project name (default: directory name)
  --verbose                   Show more output
  -v, --version               Print version and exit
  -H, --host HOST             Daemon socket to connect to

  --tls                       Use TLS; implied by --tlsverify
  --tlscacert CA_PATH         Trust certs signed only by this CA
  --tlscert CLIENT_CERT_PATH  Path to TLS certificate file
  --tlskey TLS_KEY_PATH       Path to TLS key file
  --tlsverify                 Use TLS and verify the remote
  --skip-hostname-check       Don't check the daemon's hostname against the name specified
                              in the client certificate (for example if your docker host
                              is an IP address)
  --project-directory PATH    Specify an alternate working directory
                              (default: the path of the Compose file)

Commands:
  build              Build or rebuild services
  bundle             Generate a Docker bundle from the Compose file
  config             Validate and view the Compose file
  create             Create services
  down               Stop and remove containers, networks, images, and volumes
  events             Receive real time events from containers
  exec               Execute a command in a running container
  help               Get help on a command
  images             List images
  kill               Kill containers
  logs               View output from containers
  pause              Pause services
  port               Print the public port for a port binding
  ps                 List containers
  pull               Pull service images
  push               Push service images
  restart            Restart services
  rm                 Remove stopped containers
  run                Run a one-off command
  scale              Set number of containers for a service
  start              Start services
  stop               Stop services
  top                Display the running processes
  unpause            Unpause services
  up                 Create and start containers
  version            Show the Docker-Compose version information

[koelle25]

log-level doesn't appear to be supported with my version of docker-compose:

@danwelcome This is actually a command for the image/container, not for Docker itself. Besides it's loglevel (without the hyphen). So you should use it like so:

openldap:
    image: osixia/openldap:latest
    [...]
    command: --loglevel debug

Or when running directly:
docker run [...] osixia/openldap:latest --loglevel debug

I am facing a similar issue. The first start works, but after stopping the following starts won't succeed. This seems to be a major issue, as multiple issues (#282, #285, #286) relate to this as well.

[avoidik]

I have faced this issue too, here is debug log

https://gist.github.com/avoidik/f02869c61fd072856e372a8b5d6fb6ff

[BertrandGouny]

@avoidik to you have the issue with 1.2.4-dev image tag ?

[avoidik]

on a :latest docker image, AFAICS the problematic part is here, I'll try to set LDAP_BASE_DN

Processing file /container/service/slapd/assets/config/admin-pw/ldif/07-admin-pw-change.ldif
5c6c094e conn=1002 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
5c6c094e conn=1002 op=0 BIND dn="" method=163
5c6c094e conn=1002 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
5c6c094e conn=1002 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71
5c6c094e conn=1002 op=0 RESULT tag=97 err=0 text=
5c6c094e conn=1002 op=1 do_modify: invalid dn (cn=admin,)
5c6c094e conn=1002 op=1 RESULT tag=103 err=34 text=invalid DN
5c6c094e conn=1002 op=2 UNBIND
5c6c094e conn=1002 fd=12 closed
ldap_modify: Invalid DN syntax (34)
	additional info: invalid DN
modifying entry "cn=admin,"
*** /container/run/startup/slapd failed with status 34

*** Run commands before finish...
*** Killing all processes...
5c6c094e conn=1003 fd=12 ACCEPT from IP=127.0.0.1:58186 (IP=127.0.0.1:389)
5c6c094e conn=1003 op=0 do_bind: invalid dn (cn=admin,)
5c6c094e conn=1003 op=0 RESULT tag=97 err=34 text=invalid DN
5c6c094e conn=1003 op=1 UNBIND
5c6c094e conn=1003 fd=12 closed
ldap_bind: Invalid DN syntax (34)
	additional info: invalid DN
5c6c094e daemon: shutdown requested and initiated.
5c6c094e slapd shutdown: waiting for 0 operations/tasks to finish
5c6c094e slapd stopped.

[obourdon]

Folks, again, please make sure you include all necessary information so that others do not waste time trying to figure out how to reproduce your issues. The problem here is linked to the fact that you use existing database and potentially configuration files.

I managed to reproduce it using the following scenario:

rm -rf TESTS && mkdir -p TESTS/config TESTS/database

# 1st time used to create database and config
docker run --volume $PWD/TESTS/database:/var/lib/ldap --volume $PWD/TESTS/config:/etc/ldap/slapd.d --env LDAP_TLS=false --detach osixia/openldap:1.2.3

# IMPORTANT the following only works if osixia/openldap is the only running container
docker kill $(docker ps -q)

# This second run will fail
docker run --volume $PWD/TESTS/database:/var/lib/ldap --volume $PWD/TESTS/config:/etc/ldap/slapd.d --env LDAP_TLS=false --detach osixia/openldap:1.2.3 --loglevel debug

[obourdon]

Forgot to mention that using 1.2.2 previous scenario works perfectly well

[avoidik]

Yes, right. I have

    volumes:
      - ${VOLUMES_ROOT}/ldap-data:/var/lib/ldap
      - ${VOLUMES_ROOT}/ldap-config:/etc/ldap/slapd.d
      - ${COMPOSE_ROOT}/ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom

[obourdon]

I think I have identified the commit which introduce this issue:
https:/osixia/docker-openldap/commit/7e4eaa8370fb04a1ce4a1a6d1132a0f7f9bd8aef
@alexandrst88 @BertrandGouny

[obourdon]

Please note that I have written a test for this issue:
https:/obourdon/osixia-docker-openldap/commit/e41b2bc991375380b7456ff011a0287db8040fcf

[obourdon]

Fix available #294

[BertrandGouny]

thanks to @obourdon
Fix have been merged in 1.2.4 branch, and can be tested with image tag 1.2.4-dev
waiting your feedback to release 1.2.4 :)

[obourdon]

@BertrandGouny thanks to you for the merges. Tested the 1.2.4-dev hot fix branch and seem working like a charm for me.
BTW I sometimes have test failures running on MacOSX (never got any on Linux) due to the fact that wait_process slapd is successful but then the call to ldapsearch does not succeed as the server is not fully launched yet (longer startup I guess) but this does not happen on a regular basis
Any clue about this ?

[obourdon]

@danwelcome may be this issue can now be closed ?

[danwelcome]

I pulled the 1.2.4-dev image and all seems good. Thanks for resolving!

[trijenhout]

Thanks for fixing, this works for my (Y). other notice the 1.2.4-dev at this moment gives me a match smaller ram size 750MB (afther a day or so, non or verry litle usage it cools down to 45MB) on start to 45 MB. dont no way. (1.2.2 -> 1.2.4 (1.2.3 never worked))...

[adarshaJha]

got same error with 1.2.4-dev image, so frustrating that the same yaml file was working before on 1.2.1 but not working now , neither on 1.2.4-dev. What are the reasons ?
i have prune system , volume , containers, images but still getiing same error.

[obourdon]

@adarshaJha please note that 1.2.4-dev is now quite old
1.3.0 is the latest official version but you can also use 1.2.5 or 1.2.4
Debug logs and yaml file would also be great for helping you.
Did you also look at the other linked issues ?