Serving files locally brings en0 down

Help
1

I recently transitioned my update servers (munki & reposado) from nginx to caddy (v0.10.0).
One server works great, but while the other (jabberwock.local in the Caddyfile below) has no trouble serving files to other machines on the network, it almost instantly loses ethernet connectivity if it attempts to download files from the sites it’s hosting. So something like curl http://server.local/file-x or wget http://server.local:8010/file-y executed locally will bring the network connection down. sudo ifconfig en0 down up will bring it back online.
It’s like there’s some looping going on, but oddly there’s nothing in the logs (either in the system logs or the caddy log) to help trouble shoot. Is there a way to increase log verbosity?
Here’s the Caddyfile. It’s pretty basic. I’ve tried commenting out gzip, browse etc but no joy…
Anyone know why this is happening?
Cheers
Phil

jabberwock.local:80 {
    root /Users/phil2/Sites/jabberwock.local/munki.jabberwock.local
    browse
    tls off
    gzip
    errors ./munki/error.log
    log ./munki/access.log
}

jabberwock.local:8010 {
    root /Users/phil2/Sites/reposado/html
    browse
    tls off
    gzip
    errors ./reposado/error.log
    log ./reposado/access.log
}
2

Hi Philip, can you provide more information? How do you know the interface is “going down”, what are the errors you’re getting, how are you running Caddy, what kind of system are you running on, etc?

3

Hey Matt

The machine in question is an 8 year old iMac, macos 10.12.4. It’s been running nginx with a similar setup for a few years now.
What happens is the machine just disappears off the network. I can’t even ping it. The first time this happened I thought the machine had crashed and was surprised to find it running normally apart from having no network connection.
The only way to get the network up again (apart from rebooting) was via sudo ifconfig en0 down up, so technically the interface wasn’t down but taking it down and up again fixed it until the next local http GET happened.
The logs yield nothing interesting. Any way to make the application log more chatty?

2017/05/01 19:11:50 http://jabberwock.local
2017/05/01 19:11:50 http://jabberwock.local:8010
2017/05/01 19:21:49 [INFO] SIGTERM: Terminating process

I have caddy setup to start at boot via launchd, so to rule out launchd misbehaving I started it with the same flags from the command line to compare. It ran fine for a while, but then lost connection again.

I then noticed that it only stalled when downloading over ipv6 (see below).
I have zerotier on these machines, hence all the ips, but it’s been like that for a while, and the other machine (at work) is set up the same.
Any idea what’s going on with ipv6?

wget -4 http://jabberwock.local/pkgs/AdobeInDesign8Patch-All-8.0.2.413.dmg
--2017-05-01 21:15:58--  http://jabberwock.local/pkgs/AdobeInDesign8Patch-All-8.0.2.413.dmg
Resolving jabberwock.local... 172.28.235.201, 192.168.13.72, 192.168.3.72, ...
Connecting to jabberwock.local|172.28.235.201|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 142699138 (136M) [application/x-apple-diskimage]
Saving to: ‘AdobeInDesign8Patch-All-8.0.2.413.dmg’

AdobeInDesign8Patch 100%[===================>] 136.09M  77.4MB/s    in 1.8s    

2017-05-01 21:16:00 (77.4 MB/s) - ‘AdobeInDesign8Patch-All-8.0.2.413.dmg’ saved [142699138/142699138]

phil2@jabberwock:~
→ wget -6 http://jabberwock.local/pkgs/AdobeInDesign8Patch-All-8.0.2.413.dmg
--2017-05-01 21:16:05--  http://jabberwock.local/pkgs/AdobeInDesign8Patch-All-8.0.2.413.dmg
Resolving jabberwock.local... fe80::10b2:497c:7066:ed33, fe80::b014:68ff:fe18:8714, fe80::ecce:82ff:fe18:8714, ...
Connecting to jabberwock.local|fe80::10b2:497c:7066:ed33|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 142699138 (136M) [application/x-apple-diskimage]
Saving to: ‘AdobeInDesign8Patch-All-8.0.2.413.dmg.1’

g.1                  40%[=======>            ]  55.59M  --.-KB/s    eta 60s
4

That’s a 64-bit Mac, right? (Caddy isn’t available for 32-bit Macs because, well, they’re so uncommon. You can compile it manually in that case.)

I feel like if the device is disappearing from the network entirely, it’s not a Caddy issue. Needless to say, I’ve never heard of anything like this.

Anyway, I have no clue. But there’s a lot of cruft in your setup. An init system, an old mac, ipv6, etc… trim it down as much as you can and I’d be interested in what you discover!

5

100% total hunch here, based on no theory and pure anecdote… but if you have access to the iMac, are you able to ping your client from the server when the server next “disappears” and then go to the client and try access it again?

6

Yep, it’s 64-bit. It may be old, but i like to keep it running as lean as possible. The other machines are a 2009 Mac Pro and a 2011 Mac Mini, and they’re coping well - same setup with zerotier, nothing else.
I agree, it certainly looks like there’s something up with the iMac, but it’s really hard to pinpoint as there are practically no logs, and this is a phenomenon I haven’t encountered before. How do I get caddy to log more? I tried -vvv but just got the usage info.
Now looking at my old nginx config I realize that it was always set up ipv4 only, and adding listen [::]:80 leads to the same weirdness! So that’s sorted.
So now for the time being I’ve added bind 192.168.20.21 to the server blocks until I figure out what’s going on with ipv6
on this machine. I’ll report back any findings

Anyway thanks alot for your help.

Cheers
Phil

btw ipv6 and launchd are hardly cruft, are they?

Whitestrake: I tried that, but got no pings either direction, the server was totally isolated. The only connection that worked from the server was a local ipv4 download

7

It just logs what it logs. :confused: If there’s a network error within Caddy, it should definitely be logging it (and if not, that’s probably a bug).

Yep, almost half the time the problem ends up being a problem with the launcher or the way it is being used; IPv6 isn’t “cruft” per-se but in your case, you said yourself that it was a difference between nginx and Caddy, so yes, that’s cruft. Any variables that make the experiments opaque is cruft in my book!

Still suspicious of the system or network though…

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.