caddyserver
Caddy fails to start with error on log file creation
I am using same config as i used prior, but newer caddy version
v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=
The following is in the caddy file
log {
output file /var/log/caddy/access.log
level info
format json
}
Full error
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: caddy.HomeDir=/var/lib/caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: caddy.Version=v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.GOOS=linux
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.GOARCH=amd64
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.Compiler=gc
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.NumCPU=2
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.GOMAXPROCS=2
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: runtime.Version=go1.23.4
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: os.Getwd=/
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: LANG=en_US.UTF-8
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: NOTIFY_SOCKET=/run/systemd/notify
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: HOME=/var/lib/caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: LOGNAME=caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: USER=caddy
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: INVOCATION_ID=6d5b2272b4eb4b1288d7a472920c2093
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: JOURNAL_STREAM=8:30566
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: SYSTEMD_EXEC_PID=3076
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: {"level":"info","ts":1738255192.921902,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: {"level":"info","ts":1738255192.928843,"msg":"adapted config to JSON","adapter":"caddyfile"}
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: {"level":"warn","ts":1738255192.9288704,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
Jan 30 11:39:52 ip-10-2-40-19 caddy[3076]: Error: loading initial config: loading new config: setting up custom log 'log0': opening log writer using &logging.FileWriter{Filename:"/var/log/caddy/access.log", Mode:0x0, Roll:(*bool)(nil), RollSizeMB:0, RollCompress:(*bool)(nil), RollLocalTime:false, RollKeep:0, RollKeepDays:0}: open /var/log/caddy/access.log: permission denied
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: caddy.HomeDir=/var/lib/caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: caddy.Version=v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.GOOS=linux
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.GOARCH=amd64
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.Compiler=gc
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.NumCPU=2
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.GOMAXPROCS=2
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: runtime.Version=go1.23.4
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: os.Getwd=/
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: LANG=en_US.UTF-8
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: NOTIFY_SOCKET=/run/systemd/notify
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: HOME=/var/lib/caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: LOGNAME=caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: USER=caddy
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: INVOCATION_ID=0ee05485df734ad191eff26dc14af2fd
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: JOURNAL_STREAM=8:32505
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: SYSTEMD_EXEC_PID=3372
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: {"level":"info","ts":1738255208.5533314,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: {"level":"info","ts":1738255208.5939028,"msg":"adapted config to JSON","adapter":"caddyfile"}
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: {"level":"warn","ts":1738255208.6011407,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
Jan 30 11:40:08 ip-10-2-40-19 caddy[3372]: Error: loading initial config: loading new config: setting up custom log 'log0': opening log writer using &logging.FileWriter{Filename:"/var/log/caddy/access.log", Mode:0x0, Roll:(*bool)(nil), RollSizeMB:0, RollCompress:(*bool)(nil), RollLocalTime:false, RollKeep:0, RollKeepDays:0}: open /var/log/caddy/access.log: permission denied
The path caddy/access.log did NOT exist prior to starting caddy.Changing ownership of access.log to 'caddy:caddy' from root resolves the issue
Was
caddyever run as something other than thecaddy:caddyuser/group?
Nou, always a installation and permissions standalone.. my temporal fix was remove the logging part from the Caddyfile, this was happen in a Fedora Server 41
That's very odd... Caddy will only ever create a log file owned by its current user. It must have been run as root at one point.
I had the same issue, in my case it was because I run caddy validate as root, which created the log files as root. I don't think this command was creating log files before (although I didn't check), as I didn't have this bug in a previous version of caddy.
That'd do it...
Closing, since I don't think there's anything actionable for us here.
I think it's actually a bug that caddy validate creates log files.It should just check the config and not create any file.
Closing, since I don't think there's anything actionable for us here.
I understand that there might not be an immediate action item, but I still believe this behavior deserves some attention.
The core concern is that caddy validate performs filesystem writes — specifically, creating missing log files — which goes against the expectation of a validation command being read-only and side-effect-free, as in version 2.8.x and below.
Validation commands are typically used in CI pipelines or dry-run checks (my tipical command after a Caddyfile edit is, as root, caddy validate && service caddy restart), where no changes should occur. If validate modifies the environment (even minimally), it can lead to unintended consequences or complicate automation setups.
Would it be possible to revisit this behavior, or at least clarify in the documentation that validate may write to disk?
I don't know if we've ever suggested that caddy validate has no side-effects. In fact, the docs already say that it fully provisions all the modules (which means, sets them up) -- so, like, it follows that a log file is created to provision logging. You can't validate that a log file can be created if you don't create a log file.
Regardless, the behavior of caddy validate is well beyond the scope of this issue and should be in a new one if it is to be discussed, as it would affect every living module in the Caddy ecosystem.
It would be strange to run caddy validate in order to test if the log files is correctly created. The command validates the config syntax, nothing more. At least, that's what we expect when we run this kind of command. Like @endelwar, I'm using this command in an automation tool (Ansible), which run config validate as root, and I can't choose another user to run the command. So this new behavior will make automation more complex.
Regardless, the behavior of caddy validate is well beyond the scope of this issue and should be in a new one if it is to be discussed, as it would affect every living module in the Caddy ecosystem.
The issue here is that the behavior of caddy validate changed recently, and I'm not aware it was intentional or mentioned in the release notes, hence for me this is a bug.