404 after docker compose up
dsavicIre opened this issue · comments
Describe the bug
After docker compose (Raspberry Pi 5) app seems to be working but not able to access it only getting 404
No logs of any kind.
To Reproduce
dsavic@rpi5:~/stump $ docker compose logs -f
WARN[0000] /home/dsavic/stump/docker-compose.yaml: version is obsolete
stump | Adding group stump with gid 1000
stump | Adding group stump' (GID 1000) ... stump | Done. stump | Adding user stump with uid 1000 stump | Adding system user stump' (UID 1000) ...
stump | Adding new user stump' (UID 1000) with group stump' ...
stump | Not creating home directory `/home/stump'.
docker compose :
version: '3.3'
services:
stump:
image: aaronleopold/stump:nightly
container_name: stump
# Replace my paths (prior to the colons) with your own
volumes:
- /home/dsavic/stump/stumpconf:/config
- /home/dsavic:/data
ports:
- 10801:10801
environment:
- PUID=1000
- PGID=1000
# This `environment` field is optional, remove if you don't need it.
# I am using it as an example here, but it's actually a default value.
- STUMP_CONFIG_DIR=/config
- STUMP_VERBOSITY = 3
restart: unless-stopped
Expected behavior
access through local network.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: [e.g. macOS, Windows, Linux, iOS, watchOS, Android]
Smartphone (please complete the following information):
- Device: [e.g. iPhone12, Samsung S10, etc.]
- OS: [e.g. iOS15.4.1]
Additional context
Add any other context about the problem here.
Hey 👋 Is this a new installation or new behavior after updating the nightly image?
No logs of any kind.
...
STUMP_VERBOSITY = 3
3 is a fairly noisy log level. If you were actually hitting the app, it would fill the console with output. This makes me believe it might be a network issue, not a Stump issue. I'll be able to debug a bit more after work, though.
Is this 404 screenshot on the host machine? If not, can you confirm access on the host machine, directly? If there is any activity in the console or network tab, please share it, too.
HI,
yes it is on the host machine. I had it running few months back and then stopped using it started from strach again and how |I am not getting anything.
I have caddy but even when I stop caddy same behavior is there.
I am not getting any logs at all anywhere.
Can you confirm the correct values are present in your Stump.toml config file? Based on your compose file, it would be /home/dsavic/stump/stumpconf/Stump.toml
HI,
Here it is 👍
profile = "release"
port = 10801
verbosity = 0
client_dir = "/app/client"
config_dir = "/config"
allowed_origins = []
pdfium_path = "/lib/libpdfium.so"
disable_swagger = false
password_hash_cost = 12
session_ttl = 259200
expired_session_cleanup_interval = 86400
Thanks for looking into it.
Dejan
I reverted back to original values pulled again in the new folder after clearing image and container.
I mean it is still the same 404 and no logs ....
Any idea how to get logs to start generating ?
ok figured it out
once I removed from docker compose reference to nightly in the image it all worked out.
image: aaronleopold/stump:nightly -> image: aaronleopold/stump
not sure why ...
verbosity = 0
The STUMP_VERBOSITY environment isn't overriding the default 0, so that's definitely a bug and would explain why you don't see any logs with your config
aaronleopold/stump:nightly -> image: aaronleopold/stump
My guess is you were in a state from whatever version you were running originally, which is erroring in the latest nightly image but not in the current 0.0.1. I can't replicate your 404 issues yet, both on my own personal instance and a few I put together locally. If you decide to pop back to the nightly and bump the verbosity value to something like 3 in the toml config file, please send any logs that might be helpful to debug
Thanks very much for the help, I will let you know if there is anything further to report on this.
Same with v0.0.2 release. https://hub.docker.com/layers/aaronleopold/stump/0.0.2/images/sha256-75d9060c73092b38561c924280298bc1c841bcf1a7f8ef32bef4824326249651?context=explore
@aaronleopold Attaching logs https://gist.github.com/adityatelange/7bef6601e8c1ed02875890460955e1da
and config:
profile = "release"
port = 10801
verbosity = 3
pretty_logs = true
client_dir = "/app/client"
config_dir = "/config"
allowed_origins = []
pdfium_path = "/lib/libpdfium.so"
disable_swagger = false
password_hash_cost = 12
session_ttl = 259200
expired_session_cleanup_interval = 86400
scanner_chunk_size = 100Same with
v0.0.2release. https://hub.docker.com/layers/aaronleopold/stump/0.0.2/images/sha256-75d9060c73092b38561c924280298bc1c841bcf1a7f8ef32bef4824326249651?context=explore
Are you running on arm, as well?
So I think I figured out what is going on here. It seems like it's related to nodejs/docker-node#1335, and I realized this once I noticed the following:
The web bundle is missing in the image! The docker build is swallowing errors during the web build step, which is how it slipped through, e.g. see the latest nightly build: https://github.com/stumpapp/stump/actions/runs/8792186339/job/24127849892#step:4:5742
The first instance where this started, after pouring through the log history of the actions, seems to be here, which lines up exactly with when the migration off of pnpm landed in develop which triggers an amd64+arm64 build (experimental is amd64 only)
It seems like it only affects arm64, which also explains why I couldn't replicate the issue right away since I did most of my testing ssh'd into my server.
I'm curious how/if this issue would persist if I were to swap back to my self-hosted runner, since it is less resource constrained and might not experience the network issues. I'm not overly fond of one of the resolutions in that linked issue being to just bump the timeout, and others involve downgrading node. Regardless, I'll add some protections to the Dockerfile as to not swallow and miss the error.
I'll try to have this fully resolved by the weekend with a rebuilt 0.0.2 arm build, time permitting.
@adityatelange @dsavicIre Can you please verify the issue is resolved with the nightly tag which was built over night? A quick Look at the logs doesn't show the previous issue occurred
@adityatelange @dsavicIre Can you please verify the issue is resolved with the
nightlytag which was built over night? A quick Look at the logs doesn't show the previous issue occurred
I confirm, pages are now loading no more 404s on aaronleopold/stump:nightly@sha256:7395665ab0c2291adf70d67c4e1c7f2751322ca5572dbe1418870a762a97fdb4.
Thanks for resolving the issue quickly. Stump has got great potential, and good vision.
- happy stump user :)
Awesome! 👏 Thanks for verifying!
Once I fix the latest and 0.0.2 tags I'll close this issue out
Confirming as well , all good !
Thanks vm
The latest and 0.0.2 tags should have been corrected now. I just verified on my end locally pulling them, so I'll close this ticket out now. If you pull the updated images and still face the issue let me know and I'll re-open it