Lots of tls.issuance.acme Errors

@matt, @francislavoie,
Sorry for my typos (fixed above), clarifying:

  1. I run caddy run --environ --config Caddyfile as caddy via the service.
  2. I run caddy environ as mysefl and it outputs my environment, exactly the same as running printenv

Am I wrong to expect that caddy environ should output the environment of the active caddy process? e.g. the environment of the caddy user (in this case)? Even though I run caddy environ as me?

Fundamentally, how do I output the environment of the currently running caddy process?

PS: yes!, sudo -u is what I was looking for.

1 Like

No, its purpose is to show the environment of the current user if it would be the one running Caddy. But it’s not useful for you in this case because you’re actually running Caddy as a systemd service.

Look at your systemd service’s logs. Because it uses the run --environ flag, it prints it just before starting. You might have to scroll up a bit if it’s been running for a while.

1 Like

Thanks @francislavoie, yeah my service had been running for quite a while. So I had not noticed the environment in the logs. I can see them now deep in the logs.

BTW: I found this which is useful in my situation

sudo strings /proc/`pgrep caddy`/environ

It outputs the environment of the process.


Glad you figured it out!

I think this is where we get confused, because when you say “currently running caddy process”, that means the caddy command that you’re running, i.e. the “self” process. It sounds like what you were actually looking for was the environment of another, separate caddy process, rather than the one you were executing.

And for that, as you discovered, sudo -u or the /proc trick is good. Caddy doesn’t have an API to expose its environment to other processes.

This topic was automatically closed after 30 days. New replies are no longer allowed.