Now if I run the service I get this error and I don’t know what is causing it.
Started Caddy HTTP/2 web server.
caddy[28100]: Activating privacy features...2017/07/18 10:24:22 [INFO][plorenzo.es] acme: Obtaining bundled SAN certificate
caddy[28100]: 2017/07/18 10:24:22 [INFO][plorenzo.es] AuthURL: https://acme- v01.api.letsencrypt.org/acme/authz/v_cIP91xoxxL-EdKYYwHLgdHKPTnatGeTj
caddy[28100]: 2017/07/18 10:24:22 [INFO][plorenzo.es] acme: Trying to solve HTTP-01
caddy[28100]: 2017/07/18 10:24:23 [plorenzo.es] failed to get certificate: [plorenzo.es] error presenting token: Could not start HTTP server
systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: caddy.service: Unit entered failed state.
systemd[1]: caddy.service: Failed with result 'exit-code'.
systemd[1]: caddy.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Caddy HTTP/2 web server.
systemd[1]: caddy.service: Start request repeated too quickly.
systemd[1]: Failed to start Caddy HTTP/2 web server.
systemd[1]: caddy.service: Unit entered failed state.
systemd[1]: caddy.service: Failed with result 'exit-code'.
PD: I’m spending a lot of time and effort trying to make this work using different approaches and is getting a little bit frustrating. I know some people don’t agree, but I think it will be super useful and convenient to have an official supported way of running caddy in the background (being a server is what it will do most of the time ) on the documentation.
This part says that the certificate requisition failed because Caddy couldn’t start a server to serve the challenge response.
Missing setcap perhaps?
I’m used to seeing log output like failed to get certificate: acme: Error 4xx - urn:acme:error:* with the requester and resolved DNS in cases where public DNS doesn’t match up. Usually Error 403 if the DNS is pointing at the wrong target (because it won’t give the right challenge response), or Error 400 if the DNS isn’t set at all. This seems to be failing earlier than that.
to see if there was any problem with the permissions of the user www-data tu run caddy and I get the following error:
Activating privacy features...2017/07/19 11:28:52 [INFO] acme: Registering account for email@email.com
could not save user: making user directory: mkdir /var/www/.caddy: permission denied
I don’t understand why caddy is trying to make a folder in /var/www , as you can see in the Caddyfile the project I’m trying to serve is in the /home directory
Any idea where this folder (.caddy) can be coming from?
Because journalctl does not have line breaks, I was missing info on the log, the complete line is:
caddy[1356]: 2017/07/19 12:48:44 [plorenzo.es] failed to get certificate: [plorenzo.es] error presenting token:
Could not start HTTP server for challenge -> listen tcp :80: bind: permission denied
So now it’s clear whats is the problem, any idea how to give it permission? I already use setcap
I also tried that (version 232), but I got the following error and I didn’t know what it was so I commented it again
systemd[1]: Network Service is not active.
systemd[1]: Dependency failed for Wait for Network to be Configured.
systemd[1]: systemd-networkd-wait-online.service: Job systemd-networkd-wait-online.service/start failed with result 'dependency'.
systemd[1]: Started Caddy HTTP/2 web server.
systemd[1888]: caddy.service: Failed at step CAPABILITIES spawning /usr/local/bin/caddy: Invalid argument
systemd[1]: caddy.service: Main process exited, code=exited, status=218/CAPABILITIES
systemd[1]: caddy.service: Unit entered failed state.
systemd[1]: caddy.service: Failed with result 'exit-code'.
Ahh, I was hoping that uncommenting those would resolve any capability issues… Unfortunately I’m not that great with systemd.
All I know for sure is that it can’t get :80. If you can run it from the CLI fine and serve a site on :80, that means it’s not being taken by something else, so that basically leaves capability issues.
Any advice from someone more experienced with systemd would be appreciated.
Re: that capabilities failure: nobody has been able to solve it. I have traced the exact error message with strace, but unfortunately the message is not particularly verbose. Here is where I talk about it: Systemd and AmbientCapabilities: Invalid argument / Networking, Server, and Protection / Arch Linux Forums
This is really unfortunate because with systemd 232 I cannot run it even with setcap stuff set and the capability parameters commented out like thus far. I’ve been meaning to post to StackOverflow, but have not had the time and energy.
That’s what I do. And then I use /etc/rc.local to start Caddy on reboots. (something like nohup sudo -b -i -u myusername caddy -log process.log works great.) Much simpler.
Today I finally discovered the cause of my problem: I am running an OVH dedicated server and the kernel was version 3.14. I upgraded it to 4.11 and this solved the systemd problem! Works with the latest systemd 234.
The only thing is that I still have keep the setcap flags for the Caddy binary (sudo setcap cap_net_bind_service=+ep). If the flags are not set, it refuses to bind the ports…
Hey thanks for suggesting this. I just spent several hours going crazy trying to figure out why the damn systemd service couldn’t bind to port 80, and this was the fix. I’m on debian 9 with systemd version 232 and we need to warn users of this, it’s bound to be super common.
(Don’t use setcap, like ever. Doesn’t matter if with systemd or not. It’s like a mild form of setuid.)
You don’t need setcap with systemd because the three lines, to be uncommented as suggested above, will already grant the process the p̶e̶r̶m̶i̶s̶s̶i̶o̶n capability to listen on port 80.
systemdshould throw an error if any requested capabilities are not recognized. You would need a senior dev to champion an issue report with systemd’s devs, though. Anyway, good to hear this resolves one of the Exec issues. I wonder if there’s anything more detailed in the kernel logs if this happens, though.