Running Caddy with Supervisord crashes

Hi, I am trying to get Caddy to run in the background with Supervisord, but so far I am having some issues.

Here’s what I have so far for the config file to run caddy in the background:

[program:caddy] command=caddy -conf="/home/app/Caddyfile" -email="myemailhere" -agree autostart=true autorestart=true user=myusernamehere redirect_stderr=true stdout_logfile=/var/log/supervisor/caddy.log stdout_logfile_maxbytes=50MB stdout_logfile_backups=10

However, I keep getting the following error:

INFO spawned: 'caddy' with pid 6982 INFO exited: caddy (exit status 1; not expected) INFO gave up: caddy entered FATAL state, too many start retries too quickly

When I run the command caddy -conf="/home/app/Caddyfile" -email="myemailhere" -agree on command line, it works as expected, but when I run it Supervisord, it crashes and the log file doesn’t seem to be telling me much of what’s going on. Does anyone have any ideas of what I could do?

Modify your command to caddy -conf="/home/app/Caddyfile" -email="myemailhere" -agree -log /var/log/caddy.log and see if Caddy puts anything in there that might give you more info.

I tried that, but there is no output. However when I run the commend tail -f /var/log/supervisor/caddy.log, I get the following outputs:

Activating privacy features... done. listen tcp :2015: bind: address already in use

This line appears multiple times. The problem is that port 2015 should have been free when this error occurred as running the command from command line works.

Hmm. Empty file, or missing file? And what’s your OS?

I just figured it out.

It was missing the directory line. For example: directory=/home/app/. Now it works as expected.

Huh, I find it strange that setting (effectively) the PWD of the Caddy process resolved issues trying to bind to a (presumably) open port.

Glad to hear it’s working as expected.

I am guessing here, but supervisord could have restarted Caddy by the time you see the error about binding to an already used port.

If so, then it fails the first time with a different error message (»directory not found«?), gets restarted, the port is still listed as used by Linux (it’s 15 seconds or the like for not properly closed ports), the new instance exits with the new error message. Rinse and repeat. You see or read only the most recent and misleading one.

At least that’s the behaviour you could observe with systemd, and hence there’s the setting Restart=on-abort (does not include exit codes ≠ 0 like you experienced), with which an misconfigured caddy is not restarted in the first place.

I don’t know if there’s a setting which implements that distinction with supervisord – but this comes close (not the same!):

1 Like