pi@octopi:~ $ ps -ef | grep haproxy
pi 1188 1150 0 15:48 pts/0 00:00:00 grep --color=auto haproxy
pi@octopi:~ $ ps -ef | grep octoprint
pi 399 1 0 12:59 ? 00:00:52 /home/pi/oprint/bin/python2 /home/pi/oprint/bin/octoprin serve --host=127.0.0.1 --port=5000
pi 1190 1150 0 15:50 pts/0 00:00:00 grep --color=auto octoprint
hmmm...looks like you start Optoprint on port 5000, but you didn't use that port in your browser url.
<yourip>:5000
Thank you OllisGit for your observation. However I don't have the slightest idea what I can do about it.
I checked my other octopi-installation and compared it with your result. I think the haproxy is not running, so the incomming call from the browser on port 80 is not delegated to port 5000.
My result looks like this:
pi@octopi3:~ $ ps -ef | grep haproxy
root 801 1 0 18:00 ? 00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
haproxy 802 801 0 18:00 ? 00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
haproxy 804 802 0 18:00 ? 00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
pi 1099 1060 0 18:02 pts/0 00:00:00 grep --color=auto haproxy
try to restart the haproxy manuelly:
sudo /etc/init.d/haproxy restart
now execute the processview again: ps -ef | grep haproxy it should looks like mine.
or try curl 127.0.0.1 the result should look like a html-page.
Hi OllisGit. The result.
pi@octopi:~ $ sudo /etc/init.d/haproxy restart
[sudo] password for pi:
[....] Restarting haproxy (via systemctl): haproxy.serviceJob for haproxy.service failed because the control process exited with error code.
See "systemctl status haproxy.service" and "journalctl -xe" for details.
failed!
Result of curl command:
pi@octopi:~ $ curl 127.0.0.1
curl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused
When programs give you hints, then take those hints.
pi@octopi:~ $ service haproxy status
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset:
Active: failed (Result: exit-code) since Thu 2020-03-05 17:56:45 GMT; 12h ago
Docs: man:haproxy(1)
file:/usr/share/doc/haproxy/configuration.txt.gz
Process: 1421 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Service RestartSec=100ms exp
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Scheduled restart job, resta
Mar 05 17:56:45 octopi systemd[1]: Stopped HAProxy Load Balancer.
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Start request repeated too q
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Failed with result 'exit-cod
Mar 05 17:56:45 octopi systemd[1]: Failed to start HAProxy Load Balancer.
lines 1-13/13 (END)...skipping...
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2020-03-05 17:56:45 GMT; 12h ago
Docs: man:haproxy(1)
file:/usr/share/doc/haproxy/configuration.txt.gz
Process: 1421 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q $EXTRAOPTS (code=exited, st
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Service RestartSec=100ms expired, sched
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Scheduled restart job, restart counter
Mar 05 17:56:45 octopi systemd[1]: Stopped HAProxy Load Balancer.
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Start request repeated too quickly.
Mar 05 17:56:45 octopi systemd[1]: haproxy.service: Failed with result 'exit-code'.
Mar 05 17:56:45 octopi systemd[1]: Failed to start HAProxy Load Balancer.
Whatever technique that you're using to copy/paste that is resulting in truncated lines. And it feels like the "good stuff" is at the end of at least one of those.
At least we known that it's your haproxy that is causing this.
The http://octopi.local:5000/ command replies that the IP address to the server on octopi.local
couldn't be found.
Typing in 192.168.1.165:5000/ gives connection refused. 192.168.1.165 is the IP address to the pi.
Bummer. It sounds like the octoprint service isn't running (now?)
And yet, that netstat shows that it's listening on localhost rather than 0.0.0.0 (all network adapters). But you proved that it is running earlier and it's listening to port 5000. 
sudo netstat -tulpen|grep LISTEN
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 0 14458 483/./mjpg_streamer
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 16703 879/sshd
tcp 0 0 127.0.0.1:5000 0.0.0.0:* LISTEN 1000 16435 449/python
tcp6 0 0 :::8080 :::* LISTEN 0 14459 483/./mjpg_streamer
tcp6 0 0 :::80 :::* LISTEN 0 16048 883/haproxy
tcp6 0 0 :::22 :::* LISTEN 0 16705 879/sshd
tcp6 0 0 :::443 :::* LISTEN 0 16049 883/haproxy
I guess what you have then is to be expected for the octoprint service. Interestingly, I myself can't reach my own instance from http://octopi.local:5000/ . Perhaps something was changed in one of the releases but I seem to remember this working in the past.
Let's focus on haproxy then. Let us know if yours differs from this.
cat /etc/haproxy/haproxy.cfg
global
maxconn 4096
user haproxy
group haproxy
log 127.0.0.1 local1 debug
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
option http-server-close
option forwardfor
maxconn 2000
timeout connect 5s
timeout client 15min
timeout server 15min
frontend public
bind :::80 v4v6
bind :::443 v4v6 ssl crt /etc/ssl/snakeoil.pem
option forwardfor except 127.0.0.1
use_backend webcam if { path_beg /webcam/ }
default_backend octoprint
backend octoprint
acl needs_scheme req.hdr_cnt(X-Scheme) eq 0
reqrep ^([^\ :]*)\ /(.*) \1\ /\2
reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
option forwardfor
server octoprint1 127.0.0.1:5000
errorfile 503 /etc/haproxy/errors/503-no-octoprint.http
backend webcam
reqrep ^([^\ :]*)\ /webcam/(.*) \1\ /\2
server webcam1 127.0.0.1:8080
errorfile 503 /etc/haproxy/errors/503-no-webcam.http
I'm going to say that it's identical.
So I then run this:
cat /var/log/syslog | grep haproxy
Mar 6 09:42:33 octopi systemd[1]: haproxy.service: Succeeded.
Mar 6 09:43:16 octopi systemd[1]: Starting Ensure that haproxy certs are generated...
Mar 6 09:43:16 octopi systemd[1]: Started Ensure that haproxy certs are generated.
...to see what the syslog says about all this.
In case we did want to check on the health of your haproxy.cfg file though:
/usr/sbin/haproxy -c -f "/etc/haproxy/haproxy.cfg"
[WARNING] 065/120714 (6501) : Setting tune.ssl.default-dh-param to 1024 by default, if your workload permits it you should set it to at least 2048. Please set a value >= 1024 to make this warning disappear.
Configuration file is valid
So we like that last line; that's a good sign.
Not really sure here but we might be able to start haproxy from the command line in a session and see if it gives us any more detail. So I first check man haproxy...
/usr/sbin/haproxy -V -f "/etc/haproxy/haproxy.cfg"
If that seems to still be running then go visit your browser and try again. If it throws errors then we'd be interested to read them.
As you see nothing happend after: cat /var/log/syslog | grep haproxy
If it can't run the haproxy executable then it's probably a good idea to flash a new OctoPi image to your microSD card (or a new microSD card).
I have flashed several timed before with both Win32 DiskImager and Etcher.
But on the same microSD card. Maybe something is wrong with it so I have to get a new one.
Thank you OutsourcedGuru you have been very knowledgeable and committed.
Latest try. I flashed octopi-buster-lite-0.17.0 to a new microSD card. The problem was still there.
Then I downloaded the older octopi-stretch-lite-0.15.1 and flashed it to my first microSD card.
Voila, it works like a charm!
Nice. Hopefully you're learning some things so that you can troubleshoot in the future.
People ask me, "how do you know all this?" and I have to answer, "usually I just do an Internet search and learn as much as I can about something new".
Thank you OutsourcedGuru. Yes I have learned a lot.
I know this is an old thread, but I wanted to mention this in case anyone has the same issue.
One thing I discovered today is that you get all the same symptoms described in this thread if you do a fresh install of Octopi via the Raspberry Pi Imager tool, then disable IPv6 via the kernel command line. If you re-enable IPv6, everything starts working as it should.
I hope that helps someone!
~ Terrin2k