Hello, I noticed a weird behaviour on one of my LLDAP docker deployments. After a few days of uptime, LLDAP became unresponsive, front is not loading and LLDAP does not respond to requests. After restart, it works again for a few days and becomes unresponsive. Has anyone else had the same issue?

message has been deleted

I run Docker in the Proxmox LXC container, and use basic compose:

services:
  lldap:
    image: lldap/lldap:stable
    restart: unless-stopped
    depends_on:
      - postgres
    ports:
      - "3890:3890"
      - "6360:6360"
      - "17170:17170"
    volumes:
       - "./lldap_data:/data"
    environment:
       - UID=${UID}
       - GID=${GID}
       - TZ=${TZ}
       - LLDAP_JWT_SECRET=${LLDAP_JWT_SECRET}
       - LLDAP_KEY_SEED=${LLDAP_KEY_SEED}
       - LLDAP_LDAP_BASE_DN=${LLDAP_LDAP_BASE_DN}
       - LLDAP_LDAPS_OPTIONS__CERT_FILE=/containers/lldap/certs/fullchain.pem
       - LLDAP_LDAPS_OPTIONS__KEY_FILE=/containers/lldap/certs/privkey.pem
       - LLDAP_DATABASE_URL=postgres://${POSTGRESQL_USER}:${POSTGRESQL_PASS}@postgres/${POSTGRESQL_DB}
  postgres:
    image: postgres:14.1-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRESQL_DB}
      POSTGRES_USER: ${POSTGRESQL_USER}
      POSTGRES_PASSWORD: ${POSTGRESQL_PASS}
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

What's your LLDAP version? Can you pull the latest stable, just in case? It sounds somewhat similar to an earlier case where our logging buffered for the entire LDAP session, and there were some long-lived sessions, leading to an out of memory situation

I have 0.6.1

Huh, that's not the same issue, then. Could you enable verbose logging, let it run until it doesn't respond, and send me the logs? It might be fairly big, depending on your traffic

Just enabled verbose logging, it usually takes a day or two before it becomes unresponsive

And check the CPU and RAM usage before restarting

It barely uses more than in idle, This was the first thing I checked https://cdn.discordapp.com/attachments/1364510900039712788/1364534237885104239/0c6abeffe2e4d6bc.png?ex=680a050a&is=6808b38a&hm=7c68bc0a07678763887cdea3ae7251e826e8cd5159227044f43a0c56f9612828&

Does it respond to ldapsearch?

It does not respond to ldapsearch from same host, how to check it from inside the docker container?

Some version of docker exec

I meant that ldapsearch wasn't installed in the image, after I installed it manually - no response to ldapsearch from within the container

For instance, curl

no response

Alright, I'll have a look at the logs a bit later

What do you mean?

Some unusual setup

I didn't modify much from the example compose file. I have 2 identical deployments, both on the same version but only this one is acting out

Interesting, the last thing I see from the logs is a regular LDAP request, as part of a session. But no end of session, so it's probably something to do with LDAP and that client. It's also interesting that you have 2 deployments and only one is acting up. What is the difference between the 2? Are there services connected to one but not the other?

They both have services, one is my home deployment (home one is problematic) and the other is office, both are in LXC on Proxmox, both have a similar set of services connected

Hmm, the next step would be to grab a tcpdump of the 3 ports that LLDAP is listening to, looking for any diff with the logs (maybe see a killer query that doesn't make it to the logs)

No problem, it is my home deployment and I can just keep restarting it