Symlinks failing to resolve "no such file or directory" when running application container #450
Comments
|
This isn't an issue with symlink, at least not directly. What it's saying is that when your container starts there is something missing. When the Spring Boot buildpack runs, it adds a layer with the Spring Cloud Bindings JAR and then symlinks that file in the layer to your app files, so your app can use it. When your app container is being run, it should have that layer present, so the symlink should resolve. In this case, the layer is not there and you're getting the error. It's hard to say why it's not there with the given information. I'm definitely curious as you shouldn't see issues like this normally, if you could include the full output from building the application that would be helpful. Otherwise, you mentioned not being sure why that was there. If you don't need it, you can set The other option, if you do need it is to include the JAR file yourself (i.e in your maven or gradle config). If the buildpack sees it exists, then it won't add it a second time. That would probably also work around this issue. |
dmikusa
changed the title
|
Thanks for explaining. I actually set Here's the build output: |
This is very interesting. It's telling us that you have set this and it's picked up your setting, so this should disable contributing the cloud bindings. It should have the same effect as it seeing that you've already put the library into the classpath, see code here. Something clearly isn't working though because further down you can see that it's contributing the JAR and also the helper, which should be skipped. The only thing that comes to mind is See https://go.dev/play/p/rUoxpAUwD7_6. For example |
|
@dmikusa .. in the end, maybe I just shot myself in the foot accidentally. I made this change and it works now: wleese/demo-buildpacks@6c5d509 Note that I still think that if the bindings are enabled that this error: .. doesn't make sense to this particular user :) |
|
The memory calculator will go through your JARs and count classes as part of determining how much metaspace your app needs. The JAR it's failing on is a symlink to the actual JAR file in a different layer of the image. That layer is not present for some reason. If you run Normally, when you run Aside from that, I'm not sure. I haven't seen any reports from users that build with pack build or Spring Boot build tools about this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would seem that symlinks cause issues when found in BOOT-INF
Expected Behavior
The Spring Boot application container resulting from calling
creatorshould be runnable.Current Behavior
In my test project here → https://github.com/wleese/demo-buildpacks, I'm unable to run the resulting container.
I'm surprised I have the
spring-cloud-bindingsjar at all. I tried disabling it being contributed by a buildpack (see theenvdirectory), didn't work. I double checked my dependencies, but I'm not pulling it in directly either.Steps to Reproduce
In https://github.com/wleese/demo-buildpacks, run
docker compose up, wait for the build process to succeed by looking at the logs of thedemo-buildpackscontainer, thendocker pull localhost:5443/demo-buildpacks:latestanddocker run localhost:5443/demo-buildpacks:latestthe resulting container.The text was updated successfully, but these errors were encountered: