"
Just spent a couple hours debugging a reload(not restart) of the caddy service from the acme client and gave up.
I'll try to briefly summarize the problem/observed behaviour.
System is on 25.1.8_1
Caddy package is 2.0.1
Caddy is setup to run as www and runs nicely.
- Checking /var/run/caddy after restarting the service via GUI shows caddy.sock owned by www:www with 0220
- Applying caddy config from GUI changes that to root:www with 0220
- Restarting the service via GUI changes that back to www:www with 0220
So far so good besides the strange ownership discrepancies between applying config and restarting via GUI.
Setting up an automation in ACME to reload(!) caddy is where things get strange and I can't figure out why.
- Reload fails with log:
"loading config: loading new config: starting caddy administration endpoint: unable to set permissions (--w--w----) on /var/run/caddy/caddy.sock: chmod /var/run/caddy/caddy.sock: operation not permitted"
- Ownership/permission on caddy.sock after running that automation are root:www with 0220 regardless what they where before.
If I use a caddy restart automation in ACME, everything is fine, ownership/permissions after run are www:www with 0220.
As soon as the ownership/permission on caddy.sock is root:www with 0220 running "service caddy reloadssl" fails with the same error, "service caddy restart" reverts ist back to www:www with 0200 after which "service caddy reloadssl" also works fine from the CLI.
So something goes wrong when "service caddy reloadssl" is run via an ACME automation, at least I think that is also run via the system action from within ACME.
I failed digging through all the scripts and includes and system actions etc to identify the cause and now had to give up due to time constraints, am now using caddy restart action from ACME which is fine for now.
Hopefully this helps someone way more knowledgeable then me in all the internals of the system to narrow down the issue.
I'll try to briefly summarize the problem/observed behaviour.
System is on 25.1.8_1
Caddy package is 2.0.1
Caddy is setup to run as www and runs nicely.
- Checking /var/run/caddy after restarting the service via GUI shows caddy.sock owned by www:www with 0220
- Applying caddy config from GUI changes that to root:www with 0220
- Restarting the service via GUI changes that back to www:www with 0220
So far so good besides the strange ownership discrepancies between applying config and restarting via GUI.
Setting up an automation in ACME to reload(!) caddy is where things get strange and I can't figure out why.
- Reload fails with log:
"loading config: loading new config: starting caddy administration endpoint: unable to set permissions (--w--w----) on /var/run/caddy/caddy.sock: chmod /var/run/caddy/caddy.sock: operation not permitted"
- Ownership/permission on caddy.sock after running that automation are root:www with 0220 regardless what they where before.
If I use a caddy restart automation in ACME, everything is fine, ownership/permissions after run are www:www with 0220.
As soon as the ownership/permission on caddy.sock is root:www with 0220 running "service caddy reloadssl" fails with the same error, "service caddy restart" reverts ist back to www:www with 0200 after which "service caddy reloadssl" also works fine from the CLI.
So something goes wrong when "service caddy reloadssl" is run via an ACME automation, at least I think that is also run via the system action from within ACME.
I failed digging through all the scripts and includes and system actions etc to identify the cause and now had to give up due to time constraints, am now using caddy restart action from ACME which is fine for now.
Hopefully this helps someone way more knowledgeable then me in all the internals of the system to narrow down the issue.
