Preferred way to run caddy directly as a daemon

Help
1

Hello

I need to run Caddy on Linux as a daemon. I am not interested in creating a systemd unit file or other dependencies.
Just launching Caddy, and let it run as a daemon (until killed/stopped) by itself.
Apparently, this should be a basic use case with a simple answer, but it turns out not to be so simple.

There are two general commands to run the web server.

  • The first one, caddy run, is described to “Start the Caddy process in the foreground”, which is the opposite of what we want.

  • The second, caddy start was apparently the desired one to “run caddy and forget”, as it is described as the same as caddy run but in the background.

However, I have found the problematic situation that the background process of caddy start keeps open stdout and stderr to the terminal (on v2.7.6). This is poorly documented, with caddy start only mentioning that “On Windows, the child process will remain attached to the terminal”, with no mention about limitations on *nix systems.

Still, we can find a more restrictive description on the source code at caddy/cmd/cobra.go at master · caddyserver/caddy · GitHub

‘caddy start’ to start Caddy in the background; only do this if you will be keeping the terminal window open until you run ‘caddy stop’ to close the server.

but I do want to be able to close the terminal, so it doesn’t fit either.

Seemingly available options would be to run nohup caddy run or caddy start > /dev/null 2>&1, but they do not look like the “right” solution (albeit maybe they are?).

I would expect caddy start (maybe with some parameter) to run on background, with the parent writing the messages that it spawned the child (which the above solutions would miss), and exiting, while the child would daemonize itself closing stdout and stderr / opening /dev/null on those descriptors (stdin seems to be replaced by a socket, already).

Thus, what would be the preferred way to launch caddy directly in a terminal-to-be-closed ?

Thanks

PS: links to caddyserver.com shouldn’t count against the limit of 4 links in a post for new users

2

Why not systemd? That’s our recommendation.

If you install Caddy using one of our official package installation methods, then the service is set up for you automatically. You haven’t said which distro you’re on.

This page in the docs covers all this:

1 Like
3

Believe me I’m right there with ya, but that’s kind of impossible since when a process dies it can’t restart itself without some outside help.

Why is that problematic?

Isn’t nohup a dependency though…

I guess I am trying to understand what it is you’re actually trying to do here and why the industry standards aren’t acceptable.

4

Sure, that’s an accepted drawback.

Consider that you have an external service (e.g. nagios) that detected that the service is down, then you run ssh somehost caddy start (or even copied the binary and started it). Your ssh will linger, for the simple reason that the caddy child process is keeping a file descriptor open, so ssh waits, as it might be going to write something.
systemd provides a sanitized environment, so the old ways get forgotten, but connecting /dev/null to standard input, output, and error, and close all other file descriptors is one of the classic steps for a daemon (see daemon(7)), .

And, if that parent is closed, I’m not sure how caddy will react to that. Will it ever try to write to stdout or stderr? If it does, will it receive a SIGPIPE ? (being a web server, I suppose it’d be ignoring it, but other programs could die for this) Will it happily ignore that it is unable to write to stdout, or e.g. throw an exception?
The requisite that “you need to keep the terminal window open” is probably more strict than actually needed, but I don’t know what are the actual rules Caddy is following, or if keeping those open is ever used for anything, even.

A small one, but it would be, yeah. What I would prefer was that Caddy handled this itself.

I hear you, matt. I see how this looks like an XY problem. It may even be one and we could be doing things more complex than needed, but a public website is not suitable to tell this story. I would even need to ask before telling you privately what we are using it for. I think you would like hearing it, though. My apologies for being vague here.

I am trying to get things right, though, and that’s why I am asking here (upstream) instead of directly slapping some /dev/null redirections without fully knowing the potential implications for caddy.

5

I don’t know how to continue this discussion. I’m not sure we understand your problem statement or goals.

Like I asked earlier, why not systemd?