I’m running hugo and cloud9 ide in a docker container and when I startup hugo, the live reload feature isn’t working.
You can find my containers/code here. My docker is version 1.11 and I’ve got it using real IP addresses instead of its normal 172 game, but I tried this in a VM with an older docker (1.6 – ancient, right?) with a more normal setup and I end up with the same thing.
The site loads fine, but then Chrome starts complaining about:
WebSocket connection to 'ws://192.168.52.1:35729/livereload' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
And, sure enough, if I pop into the container and run a netstat, I see this:
# yum install -y net-tools
# netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN
tcp6 0 0 :::80 :::* LISTEN
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 89646 /root/.c9/bridge.socket
unix 2 [ ACC ] STREAM LISTENING 88537 /tmp/supervisor.sock.9
You can see the hugo on port 80 and c9 on 81, but nothing is listening at the prescribed 35729 port.
I’ve tried running the app in a more verbose mode, toggling things on/off, but I’ve not found any magic combo that gets this to work. It has worked before, but stopped
Any idea’s what I’ve mucked up? Thanks!
No, but when you say it has worked before, you could start by telling what you have changed, if possible? Docker, Hugo versions …?
That’s the thing, I’ve no idea. It’s the same docker and hugo version as before (1.11 and 0.15 respectively). As noted, I even went and tried this on an older docker version with a default network setup (in case my 1.11 docker networking changes messed something up) and saw the same effect.
I was hoping there might be some way to get, like, debug level output about why live-reload listener might not be starting.
I spent some time digging around in https://github.com/spf13/hugo/tree/master/livereload today to see if it would trigger anything for me, but so I’m a bit out of my depth with
go (tbh, I don’t even understand how the main app invokes the code in this area).
I do see where the port is coming from, in the compressed JS file it does
this.port = ..., but I don’t see a reference to that number anywhere else in the repo.
You need to travel into the Gorilla websocket third party library to find that, is my guess.
So here’s something interesting, if I take my site folder and run it with (https://github.com/jojomi/docker-hugo) instead, the watch/livereload feature works. There is one obvious difference – with jojomi’s container, the ws connection goes to the same port that the webserver is on. With my invokation, it goes to that default 35729 variant…
Yup. Something about adding “–port=80” makes this not functional. No idea why, but that causes the ws connection to attempt to use the 35729 port instead of going to port 80 like it should.
It turns out to be a known issue that the LiveReload people are already aware of, see https://github.com/livereload/livereload-js/issues/16 [WebSocket port cannot be set to 80/443]
Unfortunately, this does not work when using the standard HTTP/HTTPS 80/443 ports because browsers strip the default ports 80/443 from the script element’s src attribute such that livereload.js does not see them (tested in Chrome 35 and Firefox 30). Therefore all three following embed methods use the fallback port 35729 instead of 80 or 443…
So, it is the browsers that have changed, and not a Hugo bug.
That said, I think it can be solved by adding a new feature to allow Hugo listen on 35729 port specifically for LiveReload when
--port=443 is used. Any volunteers who want to give it a try, and contribute a Pull Request? See more at https://github.com/spf13/hugo/issues/2205