https://github.com/lldap/lldap logo
Powered by
viggy96 - Having an issue with LLDAP at the mom...
# troubleshooting
v
Having an issue with LLDAP at the moment. When I try to login, I get the message: Could not log in (invalid response to login start)" on the webpage. In the docker logs, I get 
ERROR    🚨 [error]:  | error: Database error: Failed to acquire connection from pool: Connection pool timed out
a
message has been deleted
n
It means that it can't reach the DB. Is it up? I assume it's PG or MySQL?
v
Yeah its the default database
Other messages in the log suggest that the bind users are able to get in somehow, I only see my manual login failing
But idk
Copy code
lldap:
    image: lldap/lldap:stable
    init: true
    restart: always
    networks:
      - default
      - cloud
      - media
    expose:
      - 17170
    env_file:
      - default.env
    environment:
      - LLDAP_LDAP_BASE_DN=dc=viggy96,dc=me
      - LLDAP_JWT_SECRET_FILE=/data/jwt_secret
    volumes:
      - /tank/containers/lldap:/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.lldap.loadbalancer.server.port=17170"
      - "traefik.http.routers.lldap.middlewares=private@file"
That's my docker compose config
n
The default DB is SQLite, I wouldn't expect connection problem (since it runs as part of the binary)
Note: you don't need to expose the 17170 port if traefik shares a network with LLDAP (and you probably shouldn't!)
Anything relevant in your env file?
Is the machine particularly resource constrained?
v
The env file just has UID and TZ variables
Definitely not, tons of RAM and CPU, not much utilization
n
Huh, then it's quite weird. Is it reproducible easily? Does it happen consistently?
(it seems to be https://github.com/launchbadge/sqlx/issues/3241 , so I'm not sure if I can do much to help, especially if I can't reproduce it)
v
Hmm, so its in the underlying API?
n
Especially since for SQLite we have a pool with a single connection, that should be easy to manage
If you start LLDAP in verbose mode, can you confirm that the database url starts with sqlite:// ?
(it dumps the config at the top of the logs)
v
How do I enable verbose mode with the docker container?
n
LLDAP_VERBOSE=true is the easiest
v
Would this be an issue for the env file?
Copy code
UID=33
GID=33
PUID=33
PGID=33
TZ=America/Chicago
n
No
Unless the SQLite file is not readable by that user, maybe?
v
And these are the permissions in the mounted directory:
Copy code
-rw-r--r-- 1 www-data www-data      33 Nov 20  2024 jwt_secret
-rw-r--r-- 1 www-data www-data    6086 Aug 22  2024 lldap_config.toml
-r-------- 1 www-data www-data     128 Nov 20  2024 private_key
-rw-r--r-- 1 www-data www-data 7991296 Aug 18 07:00 users.db
www-data is UID 33
n
Though it's a strange error for that
v
Okay, just wanted to make sure of that
Was anything changed with sqlx recently?
n
No. Were you running it successfully before and is that a new error?
v
Asking to maybe know if a rollback might be a temporary solution
Yeah, it was running fine before
I'll start with verbose logging
I guess its only like that while its loading, and the container isn't ready yet
Verbose logging doesn't seem to reveal anything
n
At the top of the logs, you have a dump of the config
Can you confirm that the DB url starts with sqlite?
v
I think I've got to recreate the container so it uses the new environment variable
Yes, the database URL starts with 
sqlite
n
Yeah, it shouldn't time out when creating a connection (it's a library call with no network)
You don't have anything else that reads the same SQLite file?
v
No
n
Or several instances of LLDAP on the same file?
v
No, only one instance
n
Yeah, then I think it might be that sqlx bug I was linking
PreviousNext
Powered by