Syer10
commented
11 months ago This is something we fixed in r1424, I am skeptical since it should be fixed, are you sure you are using r1424 on fedora?
Open Throun opened 11 months ago
Syer10
commented
11 months ago This is something we fixed in r1424, I am skeptical since it should be fixed, are you sure you are using r1424 on fedora?
Throun
commented
11 months ago Yes, I tested with both r1197 and r1424, same results. I also just tested them with OpenJDK 17.0.2 to see if it was something to due with the java version, but no difference I could find.
I double-checked the console output and it contains this:
13:31:11.466 [JettyServerThreadPool-41] INFO io.javalin.Javalin - Exception occurred while handling static resource
java.lang.NullPointerException: super.getResource(path) must not be null`
`at io.javalin.jetty.ConfigurableHandler.getResource(JettyResourceHandler.kt:86)`
`at io.javalin.jetty.JettyResourceHandler.handle(JettyResourceHandler.kt:41)`
`at io.javalin.http.JavalinServlet$lifecycle$2$2.invoke(JavalinServlet.kt:51)`
`at io.javalin.http.JavalinServlet$lifecycle$2$2.invoke(JavalinServlet.kt:46)`
`at io.javalin.http.JavalinServletHandler.executeNextTask(JavalinServletHandler.kt:99)`
`at io.javalin.http.JavalinServletHandler.queueNextTaskOrFinish$lambda-1(JavalinServletHandler.kt:85)`
`at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)`
`at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309)`
`at io.javalin.http.JavalinServletHandler.queueNextTaskOrFinish$javalin(JavalinServletHandler.kt:85)`
`at io.javalin.http.JavalinServletHandler.executeNextTask$lambda-11$lambda-10(JavalinServletHandler.kt:119)`
`at java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:684)`
`at java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662)`
`at java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2168)`
`at io.javalin.http.JavalinServletHandler.executeNextTask(JavalinServletHandler.kt:119)`
`at io.javalin.http.JavalinServletHandler.queueNextTaskOrFinish$lambda-1(JavalinServletHandler.kt:85)`
`at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)`
`at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2309)`
`at io.javalin.http.JavalinServletHandler.queueNextTaskOrFinish$javalin(JavalinServletHandler.kt:85)`
`at io.javalin.http.JavalinServlet.service(JavalinServlet.kt:89)`
`at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)`
`at io.javalin.jetty.JavalinJettyServlet.service(JavalinJettyServlet.kt:58)`
`at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)`
`at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)`
`at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:554)`
`at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)`
`at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)`
`at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)`
`at io.javalin.jetty.JettyServer$start$wsAndHttpHandler$1.doHandle(JettyServer.kt:52)`
`at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)`
`at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:505)`
`at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)`
`at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)`
`at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1355)`
`at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)`
`at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:181)`
`at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)`
`at org.eclipse.jetty.server.Server.handle(Server.java:516)`
`at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:487)`
`at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)`
`at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)`
`at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277)`
`at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)`
`at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)`
`at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)`
`at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338)`
`at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315)`
`at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173)`
`at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)`
`at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:409)`
`at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)`
`at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)`
`at java.base/java.lang.Thread.run(Thread.java:833)EDIT: Ok, I just tested r1424 on a clean install of Fedora KDE 39(not Kinoite), and it worked as expected, so something Fedora does with regards to their immutable systems might be the cause.
Andre-Oliveira
commented
10 months ago Have the same issue in Fedora Onyx, also an immutable spin of Fedora, but not on Arch and Ubuntu.
schroda
commented
10 months ago can you reproduce the issue with the latest preview version, enabled debug logs (via launcher or server.conf, requires server restart to take effect) and then provide the logs (logs folder in the root dir https://github.com/Suwayomi/Tachidesk-Server/wiki/The-Data-Directory)
Throun
commented
10 months ago Here's the logs, issue still persists (debug logs enabled, WebUI channel is 'preview'). application.log
schroda
commented
10 months ago does the server create a webUI dir inside the root dir and is there content inside of it, according to the logs it should exist? what happens if you download the latest webUI preview and extract it to this folder manually before starting the server?
Throun
commented
10 months ago The WebUI directory is created, and the server correctly downloads the WebUI to it if it's empty. Manually extracting the WebUI preview to the directory gives off the same errors as before.
I tested the sorayomi WebUI to see if it would make a difference. I got a similar result, but the page was the same light blue as sorayomi's startup:
So the browser must be getting something from the UI.
schroda
commented
10 months ago what does the server respond with for the different requests (browser dev tools)? is it always responding with the index.html content?
Throun
commented
10 months ago Here's what I got:
schroda
commented
10 months ago just to make sure, there is a assets folder in webUI and the requested files exist (index-3029e971.js, index-a0ebbc76.css)?
because the server can read the webUI/index.html file, but not the others and therefore, answers with the index.html file as a fallback, which causes the mime type issue.
if the folder and the files exist, something must be preventing the server from accessing them
Throun
commented
10 months ago Yeah, the folder and the files exist. Everything else about the server appears to work normally, as I could connect to it from other clients, add extensions and download manga. Perhaps Fedora's the cause, but I can't think of anything they change that would affect Tachidesk like this.
Throun
commented
10 months ago Ok, I tested Tachidesk on the other official Fedora immutable desktops. Kinoite and Onyx still don't work. However, the webUI DOES work on Silverblue, which leads me to think there is a package that is only installed in Silverblue causing the problem. I'm going to try and layer some packages onto Kinoite to hopefully narrow down the issue. In the meanwhile, here's the package lists for each spin, plus regular Fedora KDE, in case they may help: pkgs-silverblue.txt pkgs-Onyx.txt pkgs-kinoite.txt pkgs-KDE.txt
acavalin
commented
7 months ago I encountered this error since the 1.0.0 release.
I run this command (data and dl folders are empty initially):
#!/bin/sh
PWD=$HOME/suwayomi
exec /usr/bin/java \
-Dsuwayomi.tachidesk.config.server.systemTrayEnabled=false \
-Dsuwayomi.tachidesk.config.server.initialOpenInBrowserEnabled=false \
-Dsuwayomi.tachidesk.config.server.rootDir=$PWD/data \
-Dsuwayomi.tachidesk.config.server.downloadsPath=$PWD/dl \
-Dsuwayomi.tachidesk.config.server.webUIEnabled=true \
-Dsuwayomi.tachidesk.config.server.webUIInterface=browser \
-Dsuwayomi.tachidesk.config.server.webUIFlavor=WebUI \
-Dsuwayomi.tachidesk.config.server.ip=0.0.0.0 \
-Dsuwayomi.tachidesk.config.server.port=3000 \
-Dsuwayomi.tachidesk.config.server.downloadAsCbz=true \
-jar $PWD/suwayomi.jarAfter coming back to this last week, I believe I found the problem. In short, atomic versions of Fedora set $HOME to /var/home, and symlinks /home to it. However, aside from Silverblue, they create users during installation, and that change has not yet been added to the installer, so initial users still have $HOME as /home (users created after install are not affected).
My wonder is why this is an issue; there should be no functional difference between the two, and other programs I use work as they should with this 'bug'. Maybe symlinks break how the server delivers files?
Device information
Steps to reproduce
Expected behavior
The web ui should load normally.
Actual behavior
The tab Tachidesk opens is blank, accessing other pages via url gives the same result. Firefox's console shows:
The stylesheet "http://127.0.0.1:4567/static/css/2.8c49bb0a.chunk.css" was not loaded because its MIME type, "text/html", is not "text/css". The stylesheet "http://127.0.0.1:4567/static/css/main.efc3b6a7.chunk.css" was not loaded because its MIME type, "text/html", is not "text/css". The script from "http://127.0.0.1:4567/static/js/2.8953c29e.chunk.js" was loaded even though its MIME type ("text/html") is not a valid JavaScript MIME type. The script from "http://127.0.0.1:4567/static/js/main.9b92ea11.chunk.js" was loaded even though its MIME type ("text/html") is not a valid JavaScript MIME type. Uncaught SyntaxError: expected expression, got '<' Uncaught SyntaxError: expected expression, got '<'Other details
I have tried deleting all files in the WebUI folder and restarting, as well as using the Sorayomi and preview WebUI. This was tested with both preinstalled and flatpak Firefox. I tested in a VM and on a HP laptop; both were clean installs.
My personal server on Arch Linux has not faced this issue, so I presume it has something to do with Fedora.