Can't start nightly keycloak build with custom providers #37770
Comments
|
It seems to be related to #34665 We're trying to understand why our providers are detected as changed. |
The are persisted from, then compared to the current file last modified times. Is it possible that you are touching the provider jars after build was run? When it is failing to start, try running another build and doing show-config again and update the issue with anything that is different from the original properties to the new ones. |
|
Thanks for reporting this issue, but there is insufficient information or lack of steps to reproduce. Please provide additional details, otherwise this issue will be automatically closed within 14 days. |
the jars aren't touched after build
there is no difference. |
If the property sets match fully, there is no reason to expect a start error. Please provide as much of the show-config output as you can and any more details that would seem relevant to reproduction - the full series of steps you are performaing, the operating system, etc. |
|
Apologies, the jars appear indeed to be touched in the deployment environment (my previous test was a local reproduction). This explains why the new modified configuration detection logic rejects the providers. |
|
This is a variant of this issue, I figured I would share here because this post was the one that pointed us in the correct direction: SituationWe did not have the problem with Keycloak 26.1.2 After numerous builds and re-builds, we found out the following:
The extra step it needs to optimize the Quarkus project on first start causes the Fargate task to take an extra 70+ seconds to launch. But then it runs happily with our custom provider classes. Case A: Broken BuildBefore kc.sh build:
Note how the files we copy in have timestamps with milliseconds ("16:48:15.489618580") whereas the timestamp of the README.md file that ships with the Keycloak base image has an "even" timestamp ("12:27:37.000000000"). During the kc.sh build it remembers the millisecond-based timestamps for each custom provider:
Note the UNIX timestamp down to the millisecond: (1744736196816 and 1744735695489). After kc.sh build:
Note how all three file timestamps are now normalized to full seconds. Milliseconds all gone for the same command. Case B: Successful BuildSame start situation before the build:
Now I inserted the following trick to my Dockerfile when building the image. Just before running kc.sh build, I touched the two custom JAR files to make them the same modified timestamp as the README.md file:
The milliseconds are now all zeros. During the build, the persisted timestamps are now also rounded to a full second:
And after the build, still all looks sane:
And with this image deployed to Fargate, it starts up nicely. |
|
See also #38893 |
Before reporting an issue
Area
core
Describe the bug
We are trying to run nightly build of keycloak with our custom providers.
We download the nightly keycloak, build our providers against it, the execute kc.sh build ... and finally attempt to start keycloak, but it exits with "A provider JAR was updated since the last build, please rebuild for this to be fully utilized." Perhaps we're doing something wrong, but I can't seem to figure out what.
Keycloak does start with these providers unoptimized, but we would prefer to test it in as close configuration to production as possible.
Version
nightly
Regression
Expected behavior
Keycloak starts
Actual behavior
Keycloak exists with "A provider JAR was updated since the last build, please rebuild for this to be fully utilized."
How to Reproduce?
Follow my steps.
Anything else?
No response
The text was updated successfully, but these errors were encountered: