I have auto_https set to off because Iām letting the google load balancer manage tls but I still get the following logs when I start caddy. Are there further options thatāll make less of them happen?
For some reason chown 1000 /config/caddy in the docker file does nothing despite working on other directories (and I see in another post that the persist option isnāt exposed to the Caddyfile), and Iād expect it not talk about certificate maintenance or storage.
Also, I use caddy fmt -overwrite and it doesnāt change the Caddyfile, which is 70 lines long, so I assume itās complaining about a missing newline or something?
I assume the uncaught signal is related to supervise, but Iām unsure where itās coming from so it quite possibly could be unrelated to caddy and php-fpm
You used a lowercase run here instead of RUN. Iām not sure if that makes a difference
Anyways, the base caddy docker image defines a VOLUME /config, you should definitely make volumes for this and /data to persist the data.
I donāt know much about āGoogle Cloud Runā so the permissions issue for the autosave.json is probably something platform-specific, I canāt answer that specifically.
Are you talking about the "logger": "tls" lines? Thatās normal, the HTTP app always loads the TLS app which triggers those maintenance messages. Theyāre harmless, Caddy isnāt actually doing anything other than starting a routine in case itās needed.
As for the caddy fmt warning, it seems to complain about an issue on line 71, but thereās only 55 lines in the Caddyfile you posted. Are you sure youāre running the config you think you are? Canāt really answer the reason unless you actually post the config youāre running.
Either way, the caddy fmt warning is just a warning, itās a suggestion to take action, but you can ignore it if you donāt care (or canāt figure out the problem).
ahh, thatās why the chown does nothing. Can I change where the autosave saves to?
Theyāre harmless
Yeah, the logs are all harmless. Itās just noisy because google run is by design making the workers come up and down as needed. Iāll ignore them if I canāt remove them, but itād be nice to have less noise
but thereās only 55 lines in the Caddyfile you posted
Sorry, I forgot to mention I deleted some business logic redirects from what I post. The actual Caddyfile is 70 lines long.
You canāt change the filename, but you can change the āconfig storage locationā via the XDG_CONFIG_HOME env var. The base Docker image sets it to /config already though, no reason to change it. See Conventions ā Caddy Documentation
The autosave is really there for the config API usecase of Caddy, where you used the API to manipulate the config inhmemory ā saves it to file so if you restart Caddy you donāt lose any config changes and can use --resume to load from the autosave. But if you use a Caddyfile, then itās not useful for you.
Please post your unredacted config. I canāt really suggest anything on the fmt point otherwise.
Your post gave the idea that we could have a caddy fmt --diff mode which would show which lines differ. I wrote that up real quick here:
Iām unsure how to build a local caddy with the two modules I use though so I canāt run it with that caddy binary without removing supervise and the jsonformat stuff, and if I do that it no longer complains about the formatting
Thatās strange. Is there a newline or something in the env var value? The formatter should be running before the env var is replaced though, so Iām confused. I canāt replicate an issue with just that line
so stackdriver sees them better. Seems that first one happens before itās read though.
The fmt messages goes away when I can use 2.5.0
Having the ānot using adminā as an info instead of warning would be nice, but oh well.
For shut down, itād be cool if the exiting message was info instead of warning. And Iām still figuring out how to make it so php-fpm is gone before cloud run thinks the caddy process is finished (cause caddy finishes before php-fpm does) and then thatāll remove the error log
