xxxxx@xxxxx:~$ sudo usermod -a -G caddy <username>
xxxxx@xxxxx:~$ sudo systemctl start caddy
xxxxx@xxxxx:~$ sudo systemctl status caddy
● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset:>
Active: failed (Result: exit-code) since Sat 2021-08-07 20:45:14 UTC; 8s a>
Docs: https://caddyserver.com/docs/
Process: 207311 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/>
Main PID: 207311 (code=exited, status=1/FAILURE)
Aug 07 20:45:14 xxxxx.org caddy[207311]: HOME=/var/lib/caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: LOGNAME=caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: USER=caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: INVOCATION_ID=5abefe79734846929>
Aug 07 20:45:14 xxxxx.org caddy[207311]: JOURNAL_STREAM=9:2060820
Aug 07 20:45:14 xxxxx.org caddy[207311]: {"level":"info","ts":1628369114.4773364,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Aug 07 20:45:14 xxxxx.org systemd[1]: Started Caddy.
Aug 07 20:45:14 xxxxx.org caddy[207311]: run: loading initial config: loding new config: starting caddy administration endpoint new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use
Aug 07 20:45:14 xxxxx.org systemd[1]: caddy.service: Main process exited code=exited, status=1/FAILURE
Aug 07 20:45:14 xxxxx.org systemd[1]: caddy.service: Failed with result 'exit-code'.
Tried shutting down service and starting it again, same with server, but to no avail. I use ufw and the ports are open for this service. I would like to get this up and running so I can use the SSL features on my home server when accessing outside of my home network. Thanks for any help you can provide.
That means there’s already something else listening on port 2019. Did you run Caddy with caddy start beforehand (this runs an instance of Caddy in the background, not managed by systemd)? If so, run caddy stop to tell it to stop. Otherwise, look for what else may be running and using that port.
I appreciate your response Francis. I had run Caddy with caddy start after trying and failing with systemctl earlier today. After your more recent suggestion, I ran netstat to try to gather some port assignment information (here is a truncated output on port 2019):
netstat -nlp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:2019 0.0.0.0:* LISTEN 202434/caddy
It appears to me that caddy was assigned to port 2019. After that, I used your suggestion and ran the caddy stop command. Running netstat -nlp after stopping caddy showed that nothing was using port 2019. Running caddy start and then sudo systemctl status caddy shows the same ‘Active:failed’ error as earlier.
Hi Francis. I should clairify that I used caddy start followed by caddy stop yesterday, before going on to try sudo systemctl caddy start and then shutting it down with sudo systemctl caddy stop. Both methods yesterday gave me a fail status.
After your post this morning, I checked that caddy was not running and after updating and restarting my server I used your suggestion sudo systemctl caddy start. However, I am still receiving the same fail message when using sudo systemctl caddy status. Just to be thorough I ran sudo systemctl caddy stop at the end, but it shouldn’t matter because it wasn’t running to begin with.
I’m at a loss right now- caddy appears to have installed the correct arm version for my Pi 4, doesn’t appear to be missing any dependencies, and the port only appears to be assigned to caddy. I could try to purge it and reinstall, but not sure that that would make any difference in this instance.
Matt- yes, you are correct. Both Francis and I were inverting the syntax order in our recent discussion, but despite our mistake in the forum, I was using the correct sudo systemctl start caddy command in the terminal. My mistake- sorry for the error, but it is definitely not a command error in the terminal. You can see the correct commands listed in the actual outputs above. Any ideas? Thanks.
I’m a little lost what steps you tried in what order. Can you post the entire terminal input and output showing that Caddy service fails to start, that something else is using port 2019, that that process using it is terminated and not automatically restarted, and that caddy still fails to start?
I allowed ufw 2019/tcp and Lighttpd HTTP, and HTTPS, and Full (briefly mentioned above). Probably didn’t matter as it should be running before being exposed anyway, and port 2019 is not necessary as I understand it for the automatic HTTPS feature once up and running.
Tried to start caddy:
xxxxx@xxxxx:~$ sudo usermod -a -G caddy <myusername>
xxxxx@xxxxx:~$ sudo systemctl start caddy
xxxxx@xxxxx:~$ sudo systemctl status caddy
● caddy.service - Caddy
Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset:>
Active: failed (Result: exit-code) since Sat 2021-08-07 20:45:14 UTC; 8s a>
Docs: https://caddyserver.com/docs/
Process: 207311 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/>
Main PID: 207311 (code=exited, status=1/FAILURE)
Aug 07 20:45:14 xxxxx.org caddy[207311]: HOME=/var/lib/caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: LOGNAME=caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: USER=caddy
Aug 07 20:45:14 xxxxx.org caddy[207311]: INVOCATION_ID=5abefe79734846929>
Aug 07 20:45:14 xxxxx.org caddy[207311]: JOURNAL_STREAM=9:2060820
Aug 07 20:45:14 xxxxx.org caddy[207311]: {"level":"info","ts":1628369114.4773364,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Aug 07 20:45:14 xxxxx.org systemd[1]: Started Caddy.
Aug 07 20:45:14 xxxxx.org caddy[207311]: run: loading initial config: loding new config: starting caddy administration endpoint new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use
Aug 07 20:45:14 xxxxx.org systemd[1]: caddy.service: Main process exited code=exited, status=1/FAILURE
Aug 07 20:45:14 xxxxx.org systemd[1]: caddy.service: Failed with result 'exit-code'.
Ran sudo systemctl stop caddy
Ran caddy start
Checked status using sudo systemctl status caddy thinking that it would show up as a process anyway. Ran netstat -nlp and saw that port 2019 was used only by caddy:
netstat -nlp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:2019 0.0.0.0:* LISTEN 202434/caddy
Same fail as earlier.
Ran caddy stop
Next day, updated and shutdown my server. Tried all of the above again. Same fail result.
Hope that helps you see what I had tried. I’m at a loss.
Hi Matt- I believe you are correct. However, sudo systemctl stop caddy should completely halt the process. Yet, using systemctl start/stop or caddy start/stop commands all result in the same Active: failed (Result: exit-code) message when running sudo systemctl status caddy after executing any of those commands.
Do you somehow have two systemd services for Caddy enabled? What else have you tried before? I don’t understand why you would still have a Caddy process running. Did you enable the caddy-api service at some point? If so, disable it.
Since I wasn’t making any progress with Caddy, I decided to try running SWAG in a docker container. Same deal, container was running fine, but not providing an SSL cert. Looks like my ISP is blocking ports 80 and 443. So I’m assuming in this case Caddy wouldn’t work for me either? Please let me know if otherwise and I’ll give Caddy another shot.
If that’s the case, then yeah, you won’t be able to get the ACME HTTP or TLS-ALPN challenges to work. You could use the DNS challenge (which involves grabbing a build of Caddy with the appropriate plugin for your DNS provider, and configuring Caddy with the credentials for that provider) but you would need to use a different port which your ISP doesn’t block.
But the errors you were saying you were seeing were not consistent with that.
To read your logs, don’t use systemctl status, instead use journalctl -u caddy --no-pager | less. The systemctl status command truncates log lines, so you don’t see full information of what happened.