What is the problem?
After a reboot, navigating to the web interface returns a 404 status code. This happens no matter what url I use to get there. I've tried
- Navigating by
http://octopi.local
- Navigating by the local IP
- From the Pi,
curl 127.0.0.1
- Connecting via API
All return the same thing: a 404 page. I am able to SSH into the Pi and access other software running on it without problems.
What did you already try to solve it?
- Rebooting
- Restarting the Octoprint service (
sudo service octoprint reboot)
~/oprint/bin/pip install --force-reinstall OctoPrint- Restarting Octoprint in safe mode
Logs (syslog, dmesg, ... no logs, no support)
~/.octoprint/logs/octoprint.log
sudo netstat -tulpen
/etc/sysctl.conf
Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)
I don't have the printer plugged in right now, so that error message can be ignored.
- Raspberry Pi 3 Model B Rev 1.2
- CPU and RAM usage are at normal levels
- Temperature and power are normal as well
- I am running Tailscale (vpn-like software) and AdGuard Home (pi-hole like software) on the same pi, but Octoprint worked previously aside these programs. It was only after a reboot that everything broke.
- Printer firmware (although it shouldn't matter) is klipper
Hello @open-parens !
Have you tried a different browser?
Hi @Ewald_Ikemann
Yes, I've tried other browsers and devices.
I've tried Chrome and Firefox, in regular and private windows, on two different machines as well as curl on the Pi host itself. All return a 404 page.
So can you please share a complete octoprint.log without DEBUG enabled. This unnecessarily blows up the log. Instead of 414 lines, without DEBUG it's just 145 lines.
As you are running OctoPrint 1.6.1, please share the systeminfo bundle file here.
It might be useful to work out what data OctoPrint is getting, since I know with Pi-Hole users usually have to configure their own proxy setup to be able to access both at the same time.
If you enable tornado.access debug logs, you will see logged every request to the server. It shows client IPs, but unless you are connecting with port forwarding this is only a local IP so don't worry about sharing it.
Then, you can see what is generating the 404 errors to try and narrow down the problem further.
I'm not sure how to change the log level and disable DEBUG. When I run octoprint serve, the logs still appear to be in debug mode.
But here is the systeminfo bundle
octoprint-systeminfo-20210616071802.zip (34.0 KB)
@Charlie_Powell How can I enable tornado.access logs without the without the web gui, and where does it appear? I've created ~/.octoprint/logging.yaml and entered this
loggers:
tornado.access:
level: DEBUG
but I don't see a ~/.octoprint/logs/tornado.log or any entries in the main octoprint log.
EDIT: It causes them to appear in the ~/.octoprint/logs/octoprint.log. I saw them when going to http://octopi.local:5000 (or equivalent) but not with port 80.
1 Like
What does your lighthttpd config look like? Does http://[IP]:5000 work?
!!!
http://[IP]:5000 works!
I guess the mystery is "why isn't port 80 proxying to port 5000"
/etc/lighttpd/lighttpd.conf
pi@octopi ~/.octoprint> cat /etc/lighttpd/lighttpd.conf
server.modules = (
"mod_indexfile",
"mod_access",
"mod_alias",
"mod_redirect",
)
server.document-root = "/var/www/html"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.port = 80
# strict parsing and normalization of URL for consistency and security
# https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_http-parseoptsDetails
# (might need to explicitly set "url-path-2f-decode" = "disable"
# if a specific application is encoding URLs inside url-path)
server.http-parseopts = (
"header-strict" => "enable",# default
"host-strict" => "enable",# default
"host-normalize" => "enable",# default
"url-normalize-unreserved"=> "enable",# recommended highly
"url-normalize-required" => "enable",# recommended
"url-ctrls-reject" => "enable",# recommended
"url-path-2f-decode" => "enable",# recommended highly (unless breaks app)
#"url-path-2f-reject" => "enable",
"url-path-dotseg-remove" => "enable",# recommended highly (unless breaks app)
#"url-path-dotseg-reject" => "enable",
#"url-query-20-plus" => "enable",# consistency in query string
)
index-file.names = ( "index.php", "index.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )
# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.conf.pl"
include "/etc/lighttpd/conf-enabled/*.conf"
#server.compat-module-load = "disable"
server.modules += (
"mod_compress",
"mod_dirlisting",
"mod_staticfile",
)
Let me ask why you are using lighthttpd anyway? Sounds like something to do with the mishmash of services running on the box.
If OctoPi, what does sudo systemctl stop lighthttpd && systemctl restart haproxy result in? Can you hit OctoPrint on 80(http) then?
1 Like
I'm not using lighttpd intentionally, and I don't remember explicitly enabling it. I assumed that it was the service that was hosting the octoprint web interface.
pi@octopi ~/.octoprint> sudo systemctl stop lighthttpd && systemctl restart haproxy
[sudo] password for pi:
Failed to stop lighthttpd.service: Unit lighthttpd.service not loaded.
Hitting port 80 still gives me a 404.
Restarting lighttpd and haproxy this time worked! I was asked to authenticate haproxy, which I wasn't last time, so that was interesting.
Accessing the Pi on port 80 works as expected now. Thank you. Do you have a donation link or something I can do to show my appreciation?
For my education, what do you think was the problem? Was haproxy or lighttpd in a bad state? Why wouldn't rebooting the machine get them in a new, clean state?
lighttpd is configured on the same port as haproxy. You'll want to figure out what lighttpd is used for before picking the right solution.
My guess is that lighttpd was left over from when I used to run Pi Hole on the same machine. I guess I never rebooted between the time that I switched from Pi Hole (which uses lighttpd as its webserver) to AdGuard Home (which has its own webserver), and now. That was there never was the conflict between lighttpd and ha-proxy.
Thanks for all the help.
