Isn’t binding ports but not logging error either

(John B Manos) #1

I have been using caddy for two years. I started with the downloadable executable file for Mac, and I have always run Macserver. This set up has worked very well until this past week when I installed the security update 2019-003 for High Sierra

Mac server has always listened on *:80 and *:443
Using bind to the IP4 address has always allowed caddy to bind and listen and serve pages with glee for several vhosts - even with Mac server running on *:443, caddy would bind x.x.x.x:443 and all was well

I start caddy with launchctl plist in the global daemons and have no errors. Just caddy isn’t listening on the IP ports anymore. :face_with_head_bandage:

Caddy is running no problem, but it’s not serving anything and lsof doesn’t show it bound anywhere. System logs don’t have any reports of error. Caddy logs have no error.
If I check on lsof, the * ports are all httpd but no caddy to be seen.

I’m at wits end … if caddy wasn’t allowed to bind x.x.x.x, then there’d be an error in the logs, right?

I’m not sure what other info I can provide… this has worked for years and now it doesn’t but there is no log errors or even hints in the logs. My sysfoo is unable to conjure any other ideas…help!!

(Matt Holt) #2

Is there anything in your Console.app perhaps? Caddy will write a log to its usual process logs if it is running and has permissions to; otherwise it must be somewhere else in the system, like OS permissions or the launch daemon.

1 Like
(John B Manos) #3

Thanks Matt – good idea, but I have the launchd plist route standard out and error to known files in the working folders I have for caddy. All I see is “Activating Privacy Features…” in the console output.

Because it isn’t binding, and caddy can’t listen, if I leave it running long enough, it will eventually throw some errors from trying to renew certs that it failed ALPN acme challenge method… which of course it would because it can’t react to the challenges that are supposed to come on the ports it can’t listen on…

I’ve looked in system log, console, servers logs, and the caddy output logs (that are routed as mentioned above) – there’s nothing. silence.

I’ve looked for entries complaining that caddy tried to listen… nothing. I would have expected either a security log saying it was denied (and why) and I would expect caddy to have at least one line in the caddy.error.log that would say something about denied a port and an echo of the error return. but instead, nobody says anything in any log!

I’ve repeatedly run “sudo lsof” with parameters to look at port 443 and 80. I can see the server app httpd sitting on *:80. Last week, if I ran that command, I would have seen httpd on *:443 and caddy on x.x.x.x:443…

There’s nothing – logs show a normal start up for caddy. caddy is running, has a PID, I can probe it and it’s alive.

it’s just silently not listening and I can’t figure out why.

(Matt Holt) #4

Is there anything in your $CADDYPATH/locks folder? If so, delete and try again.

(John B Manos) #5

Hmmmm. I’ll look and try. Thank you!