Komga with Docker Compose on Synology DSM will not fully start up from version 1.11.3 or newer

Blazeflack commented 1 week ago

Steps to reproduce

Stop Komga project in Container Manager in Synology DSM
Clean Komga project in Container Manager in Synology DSM
Update Komga docker image in Container Manager in Synology DSM (tag: latest)
Build Komga project in Container Manager in Synology DSM
Go to Komga container and observe log tab. Wait for log to settle down.
Attempt to access Komga on configured exposed port.

Expected behavior

Komga can be reached on exposed port after updating from v1.11.2 to any newer version.

Actual behavior

Komga is unreachable, but docker container is running.

Logs

komga 1.11.2.log komga 1.11.3.log komga 1.13.0.log

Komga version

1.13.0

Operating system

Synology DSM 7.2.1

Installation method

Docker

Other details

I have tried every release (docker image tag) from 1.11.3 all the way up to 1.13.0. The experience is the same and the log files are more or less identical. The only real difference is between v1.11.2 and any of the newer versions.

By comparing the logfiles from v1.11.2 and v1.13.0 I see a few differences, but the thing that jumps out at me is the fact that v1.13.0 never seems to start up the tomcat server or initiate any of the tasks. All these things are part of the v1.11.2 log file as the last actions.

I hope I have given you all the necessary information, but if not then please let me know so I can rectify it. I'm also hoping you might have a clue as to what the issue might be.

Thanks for your time.

Acknowledgements

[X] I have searched the existing issues (open AND closed) and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have checked the FAQ.
[X] I have updated the app to the latest version.
[X] I will fill out all of the requested information in this form.

gotson commented 1 week ago

you are saying it does not start, but logs say otherwise. Can you explain what is the symptom ?

Blazeflack commented 1 week ago

Hi gotson.

Apologies for the confusion.

What I meant is that version 1.11.3 or newer does not fully start up in the same way version 1.11.2 does.

Specifically, it appears the tomcat webserver does not start on version 1.11.3 or newer. In the log for 1.11.3 and 1.13.0 there is a line about the tomcat webserver initializing, but there is no line indicating it ever starts up.

In the logfile for 1.11.2 there is a line that specifically mentions the tomcat webserver has started on port 25600.

The symptom is that the Docker container is running without direct errors, but the webserver is not started up and as such any attempt to access komga on the configured port (25600) just results in the browser showing the connection could not be established, just like when you try to visit a domain that does not exist.

I hope that clears up the confusion.

Thank you.

gotson commented 1 week ago

What's your NAS hardware / CPU architecture ?

Blazeflack commented 1 week ago

Hardware: Synology DS224+ CPU: Intel Celeron J4125, 2GHz, 4 cores

einsys commented 4 days ago

I also experienced the same symptom while using Synology NAS(DS1019+), but after waiting for about 10 minutes, the web server started up.

2024-09-27T05:38:47.759Z INFO 1 --- [main] o.s.s.web.DefaultSecurityFilterChain : Will secure Or [Mvc [pattern='/kobo/**']] with [org.springframework.security.web.session.DisableEncodeUrlFilter@3d70dab8, org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@53e6c017, org.springframework.security.web.context.SecurityContextHolderFilter@2c332922, org.springframework.security.web.header.HeaderWriterFilter@19b6b7e7, org.springframework.web.filter.CorsFilter@3d123d10, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6b8773c7, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@74534564, org.gotson.komga.infrastructure.security.apikey.ApiKeyAuthenticationFilter@1ca6323c, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@27b89e0a, org.springframework.security.web.access.ExceptionTranslationFilter@488ae823, org.springframework.security.web.access.intercept.AuthorizationFilter@6d398593] 2024-09-27T05:46:39.274Z INFO 1 --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port 25600 (http) with context path '' 2024-09-27T05:46:39.297Z INFO 1 --- [main] org.gotson.komga.ApplicationKt : Started ApplicationKt in 498.949 seconds (process running for 500.116)

gotson commented 4 days ago

" Started ApplicationKt in 498.949 seconds" looks like your NAS may not like Java very much >.<

Blazeflack commented 4 days ago

I can confirm the same symptom as @einsys, now using v1.14.0. In my case it took about 12 minutes for the webserver to start up.

2024-09-27T14:24:07.679+02:00  INFO 1 --- [main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 18 endpoint(s) beneath base path '/actuator'
2024-09-27T14:24:07.907+02:00  INFO 1 --- [main] o.s.s.web.DefaultSecurityFilterChain     : Will secure Or [Mvc [pattern='/api/**'], Mvc [pattern='/opds/**'], Mvc [pattern='/sse/**'], Mvc [pattern='/oauth2/authorization/**'], Mvc [pattern='/login/oauth2/code/**'], EndpointRequestMatcher includes=[*], excludes=[], includeLinks=true] with [org.springframework.security.web.session.DisableEncodeUrlFilter@7207cb8b, org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@27449f65, org.springframework.security.web.context.SecurityContextHolderFilter@1b09f4fb, org.springframework.security.web.header.HeaderWriterFilter@16716cc0, org.springframework.web.filter.CorsFilter@3b4a77be, org.springframework.security.web.authentication.logout.LogoutFilter@2c332922, org.springframework.security.web.session.ConcurrentSessionFilter@35266985, org.springframework.security.web.authentication.www.BasicAuthenticationFilter@5ac3c6cd, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@736de3b6, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@20fdf45a, org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter@43c25e89, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@1ff55410, org.springframework.security.web.session.SessionManagementFilter@74161ed7, org.springframework.security.web.access.ExceptionTranslationFilter@6321e29b, org.springframework.security.web.access.intercept.AuthorizationFilter@3e6b08d4]
2024-09-27T14:24:07.950+02:00  INFO 1 --- [main] o.s.s.web.DefaultSecurityFilterChain     : Will secure Or [Mvc [pattern='/kobo/**']] with [org.springframework.security.web.session.DisableEncodeUrlFilter@34329e03, org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@7d6b0636, org.springframework.security.web.context.SecurityContextHolderFilter@76a2db3f, org.springframework.security.web.header.HeaderWriterFilter@5c4404dd, org.springframework.web.filter.CorsFilter@3c971473, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@8cc5602, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@4221663d, org.gotson.komga.infrastructure.security.apikey.ApiKeyAuthenticationFilter@47b4fcd5, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@67d6b0a6, org.springframework.security.web.access.ExceptionTranslationFilter@5a1216b0, org.springframework.security.web.access.intercept.AuthorizationFilter@5e24af83]
2024-09-27T14:36:00.912+02:00  INFO 1 --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 25600 (http) with context path ''
2024-09-27T14:36:00.936+02:00  INFO 1 --- [main] org.gotson.komga.ApplicationKt           : Started ApplicationKt in 731.388 seconds (process running for 732.531)

komga 1.14.0.log

@gotson are there any types of tests we can perform for you in order to narrow down this issue further?

gotson commented 1 day ago

@gotson are there any types of tests we can perform for you in order to narrow down this issue further?

unfortunately no, i have no idea how to debug / troubleshoot this. Synology is known for being quirky, and nothing much has changed between the previous version and this one in terms of underlying dependency.

Blazeflack commented 1 day ago

I see. At least the container will actually start up, so it's mainly just an inconvenience at this point.

Since the issue began after v.11.2 I have tried to look at the changes between v1.11.2 and v1.11.3 but none of the commits between these two versions jump out as a possible smoking gun. If I wanted to test each of these commits, is there a way to build a docker image from a specific commit reference?

gotson commented 1 day ago

If I wanted to test each of these commits, is there a way to build a docker image from a specific commit reference?

you can checkout that commit and follow the instructions here https://github.com/gotson/komga/blob/master/DEVELOPING.md#docker

gotson / komga