Convert Wordpress from Apache2 on Ubuntu to Caddy 2

Help
21

Uhh, that’s odd.

Does that happen if you take it down and start it up again (without --resume, specifying the new config)?

There’s definitely nothing else clamoring for port 443?

22

I edited my Caddyfile and then ran systemctl restart caddy and I got the error in /var/log/syslog
I get the same if I try systemctl stop caddy followed by systemctl start caddy

23

What do you get from netstat -tulpn | grep 443 ?

24

Well, since I get an error starting it doesn’t start, so no output.
But when I start it with only one domain definition I get the expected:

tcp        0      0 97.107.138.194:443      0.0.0.0:*               LISTEN      17971/caddy
tcp        0      0 97.107.138.194:443      46.229.168.153:57902    TIME_WAIT   -
tcp        0      0 97.107.138.194:443      46.229.168.153:56176    TIME_WAIT   -
25

When Caddy outputs this error, it means that the OS told it that it can’t bind 443 because some other program is already using it.

I’m not sure why the OS would reject the bind attempt with this error if there’s not actually any program using it. A rejection based on permissions would be a different error entirely, for example.

26

I interpret that as “Hey, I just started another https server on that port - I can’t start another one, since I assigned it to that other server”

It’s the exact same message I would get if I tried starting a caddy https server when an apache https server was already running.

27

Can you give us the latest Caddyfile you’re using that causes this error?

28

Sure:

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile
bygden.nu {
	bind bygden.nu
	root * /var/www/bygden
	php_fastcgi unix//run/php/php7.4-fpm.sock
	file_server
	encode gzip
	log {
		output file /var/log/caddy/bygden.log
		format logfmt
	}
}

erikersara.nu {
	bind erikersara.nu
	root * /var/www/ersara
	php_fastcgi unix//run/php/php7.4-fpm.sock
	file_server
	encode gzip
	log {
		output file /var/log/caddy/ersara.log
		format logfmt
	}
}
29

Hmm. And if you try with both bind directives commented out? (Presumably they shouldn’t be / were never necessary if the earlier issue was with ufw and has since been resolved.)

30

Then it starts, but as before (see above) - only on ipv6 interface…

31

But - now, with the UFW-problem solved it actually answers on ipv4 interface as well…
So, that solved it - thanks!
Both domains running now!

1 Like
32

This topic was automatically closed after 30 days. New replies are no longer allowed.