Race condition?

Hey guys. I just wanted to thank you for all the good work on Caddy. I have finally got to the point where I dynamically add/remove end-points with the JSON API.

A tester has noticed an issue. When we install our software, we stop and restart Caddy. Then our services are started. The service responsible for communicating with caddy rebuilds our JSON API in entirety and sends it to Caddy via the admin end-point.

The tester then opened the web page and sees that the Caddy initial page is displayed.

Looking at the journal, we see Caddy starting. We see it receive and apply from the admin end-point.

But, on the very next line, we see Caddy is reading the default config and applying it.

What I have done now, is apply a timeout when our service is started (1 second). After installing, this seems to now work. So, yes, I have a work-around.

I figured I should let you know because it seems Caddy has certain start-up events that occur. There should probably be a flag (or something) where reading the default config, doesn’t overwrite the current config if it came in via an end-point before the default config was loaded. This is possibly a race condition, where a new config was sent to Caddy before it was ready.

Again, nice product and hope we get this into production for our next major release.


Interesting, can you provide more details? This is too vague to really know what’s going on. What are the specific steps that are being taken? What are the logs? And, what is “Caddy initial page”?

The caddy initial page is the slanted papers, meaning the default Caddyfile is used that came with Caddy.
There’s not much else to go on. The easiest way for us to replicate was on a clean machine. The Caddy webserver gets started at the same time as do our services by our installer. One of our services writes to Caddy webserver via JSON API.
Using this command:

curl localhost:2019/config/

We noticed the config hadn’t changed.
Using this command:

sudo journalctl -f -u caddy

We noticed Caddy receive from the JSON API end-point, but then immediately the next line was to read the saved json (because we used the alternative caddy-api.service).

I can’t really give you much more than that because the tester wipes the computer each time for testing so the journal is gone and adding the delay resolved it (although this is not a good fix, but would suffice for now).

I was thinking, isn’t there any state in Caddy for something like this? For instance, if you send via the JSON API and it hasn’t even been read in (after a reboot), would Caddy return with some error (ie: 503, Service not available)?

Thanks, but what are the logs? You’ve apparently seen them, I need to see them too (the whole log) if I’m going to fix a problem… there’s still no actionable information here.

To be clear, I mean:

  • Command that was run (including any payload)
  • Output from command
  • Behavior of web server
  • Next command that was run
  • Output from command
  • Behavior of web server
  • Full logs during the whole time

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