Logging not writing into designated file

[melbv]

1. Caddy version (caddy version):

v 2.4.6

2. How I run Caddy:

Webserver & reverse proxy manager on a VPS with multiple services hidden behind (served in part through a docker network, in part bare metal)

a. System environment:

Ubuntu 20.04

b. Command:

systemctl start/stop/reload/status caddy

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

(basic-auth) {
	basicauth / {
		user1 ########################################
		user2 ########################################
	}
}

## Check if a cookie token is set on the browser

(proxy-auth) {
	@no-auth {
		not header_regexp myid Cookie #######################
	}

	route @no-auth {
		header Set-Cookie "myreferer={scheme}://{host}{uri}; Domain=mfxm.fr; Path=/; Max-Age=30; HttpOnly; SameSite=Strict; Secure"
		redir https://auth-tools.mfxm.fr
	}
}

# Create CORS for StandardNotes extensions
(cors) {
	@origin header Origin {args.0}
	header @origin Access-Control-Allow-Origin "{args.0}"
}

(log) {
	log {
		output file /var/log/caddy/caddy.log {
			roll_local_time
		}
		format console
		level INFO
	}
}

{
	import log
}

# Pseudo site for authentication
## Sets the cookie in the browser

auth-tools.mfxm.fr {
	route / {
		import basic-auth

		header Set-Cookie "myid=##########################; Domain=mfxm.fr; Path=/; Max-Age=3600; HttpOnly; SameSite=Strict; Secure"

		header +Set-Cookie "myreferer=null; Domain=mfxm.fr; Path=/; Expires=Thu, 25 Sep 1971 12:00:00 GMT; HttpOnly; SameSite=Strict; Secure"

		redir {http.request.cookie.myreferer}
	}

	respond "Hi"
	import log
}

####.mfxm.fr {

	import proxy-auth

	encode zstp gzip
	reverse-proxy 17.27.37.14:80
        root * /var/www/html

# Enable the static file server.
        file_server

# Or serve a PHP site through php-fpm:
# php_fastcgi localhost:9000
#        php_fastcgi unix//run/php/php7.4-fpm.sock

}

tools.mfxm.fr {
	# Set this path to your site's directory.

	header {
		Access-Control-Allow-Origin *
		Access-Control-Allow-Methods GET,POST,OPTIONS
		Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Cont>
	}

	handle_path /####* {
		root * /home/####/public
		file_server
	}

	root * /var/www/html

	# Enable the static file server.
	file_server

	# serve a PHP site through php-fpm:
	php_fastcgi unix//run/php/php7.4-fpm.sock

	import log
}

3. The problem I’m having:

Despite the declaration of the log directive, nothing is written in my defined log file.
I have created the file with a sudo & file & path is chmod 666 for the caddy user to have rw rights.

4. Error messages and/or full log output:

systemctl status caddy.service

states that the log file is now being re-routed onto said file.

However, when i look into the file, it is empty:

5. What I already tried:

This worked until i wanted to changed the format from console to json and decided to delete the original file to recreate it (sudo rm && sudo touch) after which caddy did not write a single line back in.

Would you be able to let me know how to get Caddy to write in the file again?

Thanks in advance

6. Links to relevant resources:

[emilylange]

Hi

Could you please try running the following commands (with sudo):

1. rm /var/log/caddy/caddy.log
2. chown -R caddy /var/log/caddy
3. chmod 700 /var/log/caddy
4. systemctl restart caddy

and check if you can see logs in the file now?

Also, in case you overlooked it:
You don’t log in ####.mfxm.fr {}

If that didn’t help, please post:

1. systemctl cat caddy
2. ls -la /var/log/caddy/

Thank you

[melbv]

Hi NotJames

Thanks for your prompt response. I have just tried what you suggested which makes no difference.
I am not sure it is a permission issue as the logging process was working fine with a chmod 666 before i deleted the first log when trying to change the formatting from console to json.
M

PS: thanks for spotting the hash service - all corrected!

[emilylange]

Hmm okay.
Do you get logs in your log file if you revert your changes back to console from json?
Also, how did you install Caddy (binary, apt repo, etc.)?
And could you post the output of systemctl cat caddy, please?

In the worst case, you might have to enable debug in the global options Global options (Caddyfile) — Caddy Documentation and look through the service logs to see if you can spot anything that seems unusual to you via journalctl --unit=caddy --since="-1h" --no-pager -f. (-f follows, so any new logs will appear instantly. CTRL+C to exit)

And maybe post part of those debug logs.

[melbv]

I have tried switching console / json back & forth and it did not yield anything.
I installed caddy with the apt repo & below is my systemd file (through systemctl cat caddy:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

And here is an extract of log:

with the permissions at every level

So it is actually a question of permissions. No idea what to allow here tho

[melbv]

By chmod 777 the entire path, caddy can now write into the log but this is not particularly elegant

[matt (Matt Holt)]

Yikes, avoid doing 777.

Perhaps better to just use the normal permissions and give the folder and file ownership with chown -R caddy:caddy /var/log/caddy.

[melbv]

Yep - once caddy managed to write in the file with a finger-burning chmod 777 at each level of the path, i reversed the permissions for the root folders. Caddy seems happy enough and continues writing in the log file…

Thanks @emilylange for your help on this one. Odd behaviour tho if you ask me!

[francislavoie]

@melbv

Odd behaviour tho if you ask me!

I found it odd too when I learned about it, but yeah, it’s how Linux works. The x (executable) permission on directories dictates whether the directory can be seen, and every directory up the tree needs to be x as well (not just the containing dir).