Caddy2 Conatiner not picking up Caddyfile changes

Help
1

1. My Caddy version (caddy version):

Latest official Docker container

2. How I run Caddy:

docker create --name=caddy2 -e TZ=America/Chicago -p 90:90 -p 4444:443 -e PUID=1000 -e PGID=1000 -v C:\Users\user\Documents\Docker\caddy2\logs:/logs -v C:\Users\user\Documents\Docker\caddy2\caddyfile\CaddyFile:/etc/caddy/Caddyfile -v C:\Users\user\Documents\Docker\caddy2\data:/data -v C:\Users\user\Documents\Docker\caddy2\config:/config/caddy caddy:latest

Docker start caddy

(I am using different ports as I have Caddy V1 running in production. Just trying to get Caddyfile for V2 working at this point.)

a. System environment:

Docker version 19.03.8 on Windows 10.0.18363.778

b. Command:

N/A

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

3. The problem I’m having:

The docker container is not picking up changes made to the Caddyfile being mounted form the host OS.

4. Error messages and/or full log output:

I know what is causing the issues in my CaddyfIle and have already updated it. Just need Caddy now to read the updated file immediately and not several hours later.

{“level”:“info”,“ts”:1588250263.18323,“msg”:“using provided configuration”,“config_file”:"/etc/caddy/Caddyfile",“config_adapter”:“caddyfile”}
run: adapting config using caddyfile: /etc/caddy/Caddyfile:11: unrecognized directive: errors

5. What I already tried:

I have tried stopping and starting the container. I have removed and recreated the container. I have removed the container image and re-downloaded it. If I remove the container, the image, wait several hours, and try again, it then picks up the changes I made to Caddyfile 8 hours ago.

I would tend to think this is a Docker issue with its local cache, but I run 30+ different containers and do this all the time without issues on all of them, except this one

I tried this also, “docker exec caddy2 caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile”, but since the container crashes, it is not able to run on a stopped container.

6. Links to relevant resources:

2

That looks like a typo! I think you meant -p 80:80.

I guess try deleting your stopped container with docker rm or go wider with docker system prune then try again. It should work fine as described.

It might be an issue with Docker for Windows volumes not syncing or something. Docker for Windows does do some weird stuff in the compatibility layer between Windows and Linux.

3

Like I commented previously, I am using port 90 as I am running caddy v1 on the machine in production. Just trying to get a working caddyfile first. I also mentioned I tried removing the container and the image with no luck.

I had been pruning images and containers, but had not tried docker system prune. That had no effect though. I checked to make sure the container is not creating an ephemeral volumes where it might be sticking the caddyfile on first run, and there are none.

I restarted Docker itself and Docker now no longer sees the local drives. I had to reboot the host for them to return to Docker. I have seen this a few times before. I think this is a Docker issues at this point.

1 Like
4

If you’re still having issues with the volumes etc, you can change the initial command to sh -c 'cat /etc/caddy/Caddyfile' to spit out what config the container is seeing. Would help confirm whether it’s some weird caching issue or not.

2 Likes
5

Subscribing to this thread, as I’m also interested in what’s going on here. I suspect a Docker config problem but in case it’s a bug in Caddy I want to get it fixed.

6

Or, while the container is already running, use:

docker exec -it caddy2 cat /etc/caddy/Caddyfile

Just to posit a possible cause - because Docker volume mounts use inode references, if you mount a file directly, and you edit it with a method that renames/moves files (such as vim’s default behaviour - see backup, backupcopy, writebackup options), the inside of the container will retain the original file, not the one written in its place on the host filesystem. This could cause the behaviour you’re seeing.

1 Like
7

(but the issue is he couldn’t get the container running because of a syntax error :stuck_out_tongue:)

1 Like
8

(Whoops, I thought he had it running but it wasn’t reloading. Shouldn’t have skimmed that part.)

9

This is definitely a Docker issue. After a host reboot it worked as expected. The past several releases for Docker on Windows have had numerous bugs with file system mounts over the past 6 months The releases have been very unstable.

Thanks for the help!

2 Likes
10

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