starred/lldap-lldap
1
0
Fork 0
mirror of https://github.com/lldap/lldap.git synced 2026-04-25 00:05:50 +03:00
Code Issues 101 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #1290] [BUG] (Docker) Logs not respecting the Timezone #450

New issue
Open
opened 2026-02-27 08:17:22 +03:00 by kerem · 8 comments
kerem commented 2026-02-27 08:17:22 +03:00
Owner
Copy link

Originally created by @vic1707 on GitHub (Sep 15, 2025).
Original GitHub issue: https://github.com/lldap/lldap/issues/1290

Describe the bug
The docker logs don't respect the timezone passed as a direct file or as the TZ env.

To Reproduce

The timezone is successfully detected when using either a volume mount or the TZ env

# No particular settings
[bofzilla@localhost ~]$ podman run  --entrypoint date lldap/lldap
Mon Sep 15 13:38:50 UTC 2025

# ENV
[bofzilla@localhost ~]$ podman run -e TZ=Europe/Paris  --entrypoint date lldap/lldap
Mon Sep 15 15:39:02 CEST 2025

# With direct mount of TZ file
[bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro  --entrypoint date lldap/lldap
Mon Sep 15 15:44:29 CEST 2025

But when running the lldap container itself, the logs don't respect the timezone

# ENV
[bofzilla@localhost ~]$ podman run -e TZ=Europe/Paris -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' lldap/lldap
[entrypoint] Copying the default config to /data/lldap_config.toml
[entrypoint] Edit this file to configure LLDAP.
> Setup permissions..
> Starting lldap..

Loading configuration from /data/lldap_config.toml
WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message.

thread 'main' panicked at server/src/main.rs:53:10:
The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2025-09-15T13:45:45.485704342+00:00  INFO     set_up_server [ 544ms | 100.00% ]
2025-09-15T13:45:45.487293348+00:00  INFO     ┝━ ｉ [info]: Starting LLDAP version 0.6.2
2025-09-15T13:45:45.655803149+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema from version 1
2025-09-15T13:45:45.656153149+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 2
2025-09-15T13:45:45.703065094+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 3
2025-09-15T13:45:45.779727996+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 4


# Volume mount
[bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' lldap/lldap
[entrypoint] Copying the default config to /data/lldap_config.toml
[entrypoint] Edit this file to configure LLDAP.
> Setup permissions..
> Starting lldap..

Loading configuration from /data/lldap_config.toml
WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message.

thread 'main' panicked at server/src/main.rs:53:10:
The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2025-09-15T13:46:28.193615201+00:00  INFO     set_up_server [ 425ms | 100.00% ]
2025-09-15T13:46:28.194409200+00:00  INFO     ┝━ ｉ [info]: Starting LLDAP version 0.6.2
2025-09-15T13:46:28.337770024+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema from version 1
2025-09-15T13:46:28.337839032+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 2
2025-09-15T13:46:28.390690970+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 3
2025-09-15T13:46:28.513260827+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 4
2025-09-15T13:46:28.545796788+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 5
2025-09-15T13:46:28.649556667+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema to version 6

Expected behavior
The time and date in the logs should reflect the desired Timezone

Logs
ENV with verbose mode (doesn't seem to change anything)

[bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' -e LLDAP_VERBOSE=true lldap/lldap
[entrypoint] Copying the default config to /data/lldap_config.toml
[entrypoint] Edit this file to configure LLDAP.
> Setup permissions..
> Starting lldap..

Loading configuration from /data/lldap_config.toml
Configuration: Configuration {
    ldap_host: "0.0.0.0",
    ldap_port: 3890,
    http_host: "0.0.0.0",
    http_port: 17170,
    jwt_secret: Some(
        ***SECRET***,
    ),
    ldap_base_dn: "dc=example,dc=com",
    ldap_user_dn: "admin",
    ldap_user_email: "",
    ldap_user_pass: None,
    force_ldap_user_pass_reset: False,
    force_update_private_key: false,
    database_url: "sqlite:///data/users.db?mode=rwc",
    ignored_user_attributes: [],
    ignored_group_attributes: [],
    verbose: true,
    key_file: "server_key",
    key_seed: Some(
        ***SECRET***,
    ),
    assets_path: "./app",
    smtp_options: MailOptions {
        enable_password_reset: false,
        from: None,
        reply_to: None,
        server: "localhost",
        port: 587,
        user: "",
        password: ***SECRET***,
        smtp_encryption: Tls,
        ..
    },
    ldaps_options: LdapsOptions {
        enabled: false,
        port: 6360,
        cert_file: "cert.pem",
        key_file: "key.pem",
    },
    http_url: "http://localhost/",
    ..
}
WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message.

thread 'main' panicked at server/src/main.rs:53:10:
The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2025-09-15T13:47:27.578442777+00:00  INFO     set_up_server [ 497ms | 72.05% / 100.00% ]
2025-09-15T13:47:27.578763784+00:00  INFO     ┝━ ｉ [info]: Starting LLDAP version 0.6.2
2025-09-15T13:47:27.597104755+00:00  DEBUG    ┝━ get_schema_version [ 2.30ms | 0.46% ]
2025-09-15T13:47:27.605082746+00:00  DEBUG    │  ┕━ 🐛 [debug]:  | return: None
2025-09-15T13:47:27.698019645+00:00  DEBUG    ┝━ get_schema_version [ 2.90ms | 0.58% ]
2025-09-15T13:47:27.702443640+00:00  DEBUG    │  ┕━ 🐛 [debug]:  | return: Some(SchemaVersion(1))
2025-09-15T13:47:27.702676632+00:00  INFO     ┝━ ｉ [info]: Upgrading DB schema from version 1
Originally created by @vic1707 on GitHub (Sep 15, 2025). Original GitHub issue: https://github.com/lldap/lldap/issues/1290 **Describe the bug** The docker logs don't respect the timezone passed as a direct file or as the TZ env. **To Reproduce** The timezone is successfully detected when using either a volume mount or the TZ env ``` # No particular settings [bofzilla@localhost ~]$ podman run --entrypoint date lldap/lldap Mon Sep 15 13:38:50 UTC 2025 # ENV [bofzilla@localhost ~]$ podman run -e TZ=Europe/Paris --entrypoint date lldap/lldap Mon Sep 15 15:39:02 CEST 2025 # With direct mount of TZ file [bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro --entrypoint date lldap/lldap Mon Sep 15 15:44:29 CEST 2025 ``` But when running the lldap container itself, the logs don't respect the timezone ``` # ENV [bofzilla@localhost ~]$ podman run -e TZ=Europe/Paris -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' lldap/lldap [entrypoint] Copying the default config to /data/lldap_config.toml [entrypoint] Edit this file to configure LLDAP. > Setup permissions.. > Starting lldap.. Loading configuration from /data/lldap_config.toml WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message. thread 'main' panicked at server/src/main.rs:53:10: The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace 2025-09-15T13:45:45.485704342+00:00 INFO set_up_server [ 544ms | 100.00% ] 2025-09-15T13:45:45.487293348+00:00 INFO ┝━ ｉ [info]: Starting LLDAP version 0.6.2 2025-09-15T13:45:45.655803149+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema from version 1 2025-09-15T13:45:45.656153149+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 2 2025-09-15T13:45:45.703065094+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 3 2025-09-15T13:45:45.779727996+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 4 # Volume mount [bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' lldap/lldap [entrypoint] Copying the default config to /data/lldap_config.toml [entrypoint] Edit this file to configure LLDAP. > Setup permissions.. > Starting lldap.. Loading configuration from /data/lldap_config.toml WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message. thread 'main' panicked at server/src/main.rs:53:10: The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace 2025-09-15T13:46:28.193615201+00:00 INFO set_up_server [ 425ms | 100.00% ] 2025-09-15T13:46:28.194409200+00:00 INFO ┝━ ｉ [info]: Starting LLDAP version 0.6.2 2025-09-15T13:46:28.337770024+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema from version 1 2025-09-15T13:46:28.337839032+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 2 2025-09-15T13:46:28.390690970+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 3 2025-09-15T13:46:28.513260827+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 4 2025-09-15T13:46:28.545796788+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 5 2025-09-15T13:46:28.649556667+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema to version 6 ``` **Expected behavior** The time and date in the logs should reflect the desired Timezone **Logs** ENV with verbose mode (doesn't seem to change anything) ``` [bofzilla@localhost ~]$ podman run -v /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro -e LLDAP_JWT_SECRET='ofwehchnqoiheugbpqwiubxweipqufgpghfpewuhp[fhq3' -e LLDAP_VERBOSE=true lldap/lldap [entrypoint] Copying the default config to /data/lldap_config.toml [entrypoint] Edit this file to configure LLDAP. > Setup permissions.. > Starting lldap.. Loading configuration from /data/lldap_config.toml Configuration: Configuration { ldap_host: "0.0.0.0", ldap_port: 3890, http_host: "0.0.0.0", http_port: 17170, jwt_secret: Some( ***SECRET***, ), ldap_base_dn: "dc=example,dc=com", ldap_user_dn: "admin", ldap_user_email: "", ldap_user_pass: None, force_ldap_user_pass_reset: False, force_update_private_key: false, database_url: "sqlite:///data/users.db?mode=rwc", ignored_user_attributes: [], ignored_group_attributes: [], verbose: true, key_file: "server_key", key_seed: Some( ***SECRET***, ), assets_path: "./app", smtp_options: MailOptions { enable_password_reset: false, from: None, reply_to: None, server: "localhost", port: 587, user: "", password: ***SECRET***, smtp_encryption: Tls, .. }, ldaps_options: LdapsOptions { enabled: false, port: 6360, cert_file: "cert.pem", key_file: "key.pem", }, http_url: "http://localhost/", .. } WARNING: A key_seed was given, we will ignore the key_file and generate one from the seed! Set key_file to an empty string in the config to silence this message. thread 'main' panicked at server/src/main.rs:53:10: The LDAP admin password must be initialized. Either set the `ldap_user_pass` config value or the `LLDAP_LDAP_USER_PASS` environment variable. A minimum of 8 characters is recommended. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace 2025-09-15T13:47:27.578442777+00:00 INFO set_up_server [ 497ms | 72.05% / 100.00% ] 2025-09-15T13:47:27.578763784+00:00 INFO ┝━ ｉ [info]: Starting LLDAP version 0.6.2 2025-09-15T13:47:27.597104755+00:00 DEBUG ┝━ get_schema_version [ 2.30ms | 0.46% ] 2025-09-15T13:47:27.605082746+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: None 2025-09-15T13:47:27.698019645+00:00 DEBUG ┝━ get_schema_version [ 2.90ms | 0.58% ] 2025-09-15T13:47:27.702443640+00:00 DEBUG │ ┕━ 🐛 [debug]: | return: Some(SchemaVersion(1)) 2025-09-15T13:47:27.702676632+00:00 INFO ┝━ ｉ [info]: Upgrading DB schema from version 1 ```
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 15, 2025):

For simplicity and making things easier to debug, all the times are in UTC. I don't think I want to change that

<!-- gh-comment-id:3292278218 --> @nitnelave commented on GitHub (Sep 15, 2025): For simplicity and making things easier to debug, all the times are in UTC. I don't think I want to change that
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@vic1707 commented on GitHub (Sep 15, 2025):

While UTC can simplify your debugging, most users don’t actually live in UTC. When apps ignore the configured timezone, it creates unnecessary friction in real deployments (imagine having your services all in UTC but one insists on UTC-4).

For debugging, it may be enough to ask users to state their timezone (it’s usually already in a docker run or docker-compose snippet). That way the info is clear to the maintainers, but users can still run services in their local timezone.

<!-- gh-comment-id:3292334811 --> @vic1707 commented on GitHub (Sep 15, 2025): While UTC can simplify your debugging, most users don’t actually live in UTC. When apps ignore the configured timezone, it creates unnecessary friction in real deployments (imagine having your services all in UTC but one insists on UTC-4). For debugging, it may be enough to ask users to state their timezone (it’s usually already in a docker run or docker-compose snippet). That way the info is clear to the maintainers, but users can still run services in their local timezone.
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 15, 2025):

It's not so much that I want to know when you run each query (I don't care what time zone you're in), but rather that the system manipulates timestamps in UTC all over the place (e.g. creation date) and I want consistent times with the logs time.

Having only half of the timestamps be local is the worst possible outcome, and trying to determine where and when to do the correct conversions for display is unnecessary complexity that I don't want to add to the project.

The timestamps are converted to the users' local timezones in the web UI.

<!-- gh-comment-id:3292486716 --> @nitnelave commented on GitHub (Sep 15, 2025): It's not so much that I want to know when you run each query (I don't care what time zone you're in), but rather that the system manipulates timestamps in UTC all over the place (e.g. creation date) and I want consistent times with the logs time. Having only half of the timestamps be local is the worst possible outcome, and trying to determine where and when to do the correct conversions for display is unnecessary complexity that I don't want to add to the project. The timestamps are converted to the users' local timezones in the web UI.
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@vic1707 commented on GitHub (Sep 15, 2025):

Ok, thanks for the clarification, I better understand what you meant.

Wouldn't it be better if lldap used the system's timezone everywhere on boot ?
This feels way more natural and takes care of the consistency while being way more convenient for end users, doesn't it ?

Imo an app running somewhere shouldn't really care about what timezone it's on, it should just use it transparently, but I can very well be mistaken.

I didn't look into the code yet so I have no real clue of the amount of work/side effects this could have.
Tho, what could become scary would be migrations ie: users noticing the change and wanting to go to their timezones 🤔

<!-- gh-comment-id:3292882594 --> @vic1707 commented on GitHub (Sep 15, 2025): Ok, thanks for the clarification, I better understand what you meant. Wouldn't it be better if lldap used the system's timezone everywhere on boot ? This feels way more natural and takes care of the consistency while being way more convenient for end users, doesn't it ? Imo an app running somewhere shouldn't really care about what timezone it's on, it should just use it transparently, but I can very well be mistaken. I didn't look into the code yet so I have no real clue of the amount of work/side effects this could have. Tho, what could become scary would be migrations ie: users noticing the change and wanting to go to their timezones 🤔
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 15, 2025):

Timezones for anything else than display is rife with issues. DST is probably the most well known :)

Of course, what you'd want is a monotonic time (seconds since epoch) associated with a timezone for interpretation. But then, every operation except for displaying can be done on the monotonic time instead. And you wouldn't want to store the timezone in the DB, what if you run 2 instances of LLDAP in different timezones? So you end up using the monotonic time instead (UTC), and converting it as late as possible to a user-friendly format for displaying.

In your ideal world, the conversion would be before logging, but that infects the code in lots of places. In my ideal world, it's only done in the frontend :)

<!-- gh-comment-id:3292914532 --> @nitnelave commented on GitHub (Sep 15, 2025): Timezones for anything else than display is rife with issues. DST is probably the most well known :) Of course, what you'd want is a monotonic time (seconds since epoch) associated with a timezone for interpretation. But then, every operation except for displaying can be done on the monotonic time instead. And you wouldn't want to store the timezone in the DB, what if you run 2 instances of LLDAP in different timezones? So you end up using the monotonic time instead (UTC), and converting it as late as possible to a user-friendly format for displaying. In your ideal world, the conversion would be before logging, but that infects the code in lots of places. In my ideal world, it's only done in the frontend :)
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@vic1707 commented on GitHub (Sep 15, 2025):

Yeah having two instances with potentially different timezones would be a receipt for disaster 😅.

I 100% agree with you that time should be stored in UTC, sorry if my previous messages implied the opposite 🙇.

The same way nobody cares about my specific timezone, I think not a single user really cares about what is stored, it's an implementation detail.

I do prefer the world view you depicted, I think the difference lies in me believing that app logs are part of the "frontend" 😉

<!-- gh-comment-id:3293390850 --> @vic1707 commented on GitHub (Sep 15, 2025): Yeah having two instances with potentially different timezones would be a receipt for disaster 😅. I 100% agree with you that time should be stored in UTC, sorry if my previous messages implied the opposite 🙇. The same way nobody cares about my specific timezone, I think not a single user really cares about what is stored, it's an implementation detail. I do prefer the world view you depicted, I think the difference lies in me believing that app logs are part of the "frontend" 😉
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@nitnelave commented on GitHub (Sep 15, 2025):

The short of it is that if there's a way to have your cake (timezone logs) and I can eat it too (almost no added code complexity) I would probably accept it. But I probably won't be looking for it.

<!-- gh-comment-id:3293459378 --> @nitnelave commented on GitHub (Sep 15, 2025): The short of it is that if there's a way to have your cake (timezone logs) and I can eat it too (almost no added code complexity) I would probably accept it. But I probably won't be looking for it.
kerem commented 2026-02-27 08:17:22 +03:00
Author
Owner
Copy link

@vic1707 commented on GitHub (Sep 16, 2025):

Ok, I'll try looking for that then 👍

<!-- gh-comment-id:3296515735 --> @vic1707 commented on GitHub (Sep 16, 2025): Ok, I'll try looking for that then 👍
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dependabot/github_actions/codecov/codecov-action-6
copilot/fix-equality-filters-list-attributes
dependabot/github_actions/docker/build-push-action-7
dependabot/github_actions/docker/metadata-action-6
dependabot/github_actions/docker/setup-buildx-action-4
dependabot/github_actions/docker/login-action-4
copilot/update-download-artifact-action
copilot/fix-opensuse-warnings
copilot/fix-1268
copilot/fix-727
copilot/fix-898
copilot/fix-1256
copilot/fix-1251
copilot/fix-1249
copilot/fix-1206
user-attribute-form
user-ui
group-ui
server-user-attribute-schema
crates
haveibeenpwned
v0.6.2
v0.6.1
v0.6.0
v0.5.0
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.0.1
Labels
Clear labels   
backend

   
blocked

   
bug

   
cleanup

   
dependencies

   
docker

   
documentation

   
duplicate

   
enhancement

   
enhancement

   
frontend

   
github_actions

   
good first issue

   
help wanted

   
help wanted

   
integration

   
invalid

   
ldap

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
rust

   
rust

   
tests

   
wontfix
No labels
backend
blocked
bug
cleanup
dependencies
docker
documentation
duplicate
enhancement
enhancement
frontend
github_actions
good first issue
help wanted
help wanted
integration
invalid
ldap
pull-request
question
rust
rust
tests
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/lldap-lldap#450
No description provided.