caddy: access logging doesn't seem to be working
Dockerfile
FROM caddy:2.5.1-builder-alpine AS builder
RUN xcaddy build \
--with github.com/mholt/caddy-ratelimit \
--with github.com/caddyserver/transform-encoder
FROM caddy:2.5.1-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
docker-compose.yml
version: "3.7"
services:
caddy:
image: caddy:1653111634
container_name: caddy
hostname: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- /etc/localtime:/etc/localtime:ro
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- ./config:/config
- ./logs:/logs
- $HOME/lego-certificates/certificates:/certs:ro
env_file: .env
networks:
default:
name: $DOCKER_MY_NETWORK
external: true
Caddyfile
(logging) {
log {
output file /logs/access.log {
roll_size 10MiB
roll_keep 5
roll_keep_for 48h
}
# format transform "{common_log}"
format transform "{request>remote_addr} - {request>user_id} [{ts}] {request>method} {request>uri} {request>proto} {status} {size} {request>headers}" {
time_format "02/Jan/2006:15:04:05 -0700"
}
}
}
test.{$MY_DOMAIN} {
import logging
@internal-api {
path /api/internal/*
remote_ip {$SERVER_IP}
header x-internal-api-key {$INTERNAL_AUTH_KEY}
}
handle @internal-api {
reverse_proxy api:8000
}
}
The file is never created. It doesn’t matter whether I create the logs directory or let the container create it. It doens’t matter what value format is.
Changing it to something /var/log/ also doesn’t help. Changing output to stdout sometimes works and sometimes doesn’t. I make sure I do docker-compose down and up each time I change any config.
What is weird is I have the exact similar config on another server (running Debian 11) where everything works. On my Ubuntu servers (20.04 and 22.04), the log files are never created. The docker engine is the same everywhere.
The caddy logs have no relevant information.
How do I debug this situation ? I can see the access logs on my api container and enabling debug in Caddy also shows the complete log.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 21 (9 by maintainers)
I have managed to “reproduce” what you’re seeing and understand the issue.
There are 2 possible scenarios:
When Caddy logs are configured with rolling, access files are not created immediately. The access log files are created on first-write! So you may have deleted the file when Caddy/container was powered down, but do not expect the access log file to be immediately created when it’s powered up. It will be created when it it issues its first write, which is upon someone or something visiting the website.
If you delete the file while caddy/container is running, then this is an operation error which Caddy cannot help with nor prevent (read: https://www.baeldung.com/linux/open-file-handle-after-move-delete). I’m not sure what to say here… refrain from deleting files used by your web server?
Truncating the file with
> access-log-file.logdoes not show the same issue, and Caddy is still capable of writing to the file.As it stands, this is not a bug in Caddy. This is an operational error. I’ll close this bug now as
invalid, but feel free to share counter-evidence to the scenarios I outlined above.???
For the sake of not allowing this report to be hijacked by others who aren’t interested in helping, @accountForIssues, you are welcome to discuss the issue.