Improve support for systemd and daemontools

[Oppen]

Tinyproxy version

None yet, but the observations are over master.

Issue

Tinyproxy seems designed with the following rules, which were commonplace with sysvinit:

• Daemons fork themselves into the background (evidenced by the pidfile settings);
• Daemons don't rely on external data other than config files, probably because they can't guarantee the same environment each time;
• Daemons log to syslog or logfiles;
• Daemons don't notify readiness.

Currently, both systemd and most modern daemontools derivatives supervise processes, which not forking makes easier, and makes pidfiles redundant. They support file descriptor passing as well, which I'll come back to later. They capture stdout and stderr for logging. They have pipes and sockets to receive simple signs of readiness to serve.

What I propose is supporting these. It shouldn't be a lot of code and I wouldn't be against implementing (some of) it myself, but I'd like to see if the interest is there. It's several features that can be implemented separately.

• Not forking is easy, just as it is not creating the pidfile. Just a -f flag. This alone makes it supervision friendly.
• Logging to stderr/stdout is easy as well, just default to not doing anything with the global fd and set it to 1 or 2 in the source code. That helps supervisors have proper rotation rules and have separate file permissions if they need so.
• Readiness is not too complicated but slightly more involved: you need to specify an open file descriptor to receive, then you just print READY=1\n on it when you're accepting connections. That's compatible with systemd and s6 AFAICT.
• The file descriptor passing has many advantages, even though it is a bit more complicated to implement. The normal procedure is to hardcode a file descriptor number to mark as a start for received file descriptors (it could also be configured I guess) and check for the LISTEN_FDS variable to know how many follow. That should be a bound socket. That protocol is compatible with systemd and nosh out of the box, and trivially supported in run scripts in s6. Among the advantages of file descriptor passing are persistence (you can restart the daemon without losing connections or in-flight data) and security (you can bind to privileged ports while never ever launching tinyproxy with privileges).

I'm thinking of using tinyproxy as a reverse proxy, but I'd really like to be able to not hack around s6. Indeed, one of the reasons I'm considering it is that everything else is "broken" in these regards, but this one at least I feel confident I can submit patches, while the other ones are simply too big to understand.

[Oppen]

OK, looking at the code I see the default logging is already stdout. It doesn't seem documented and a very old mail in the supervision mailing list mislead me to believe it was still not supported. The same can be found about daemonizing. So only two are missing AFAICT.

[rofl0r]

the quickstart guide on the official homepage explicitly uses the options you desire. i can't see the purpose of "readiness signaling", please enlighten me. as of current master, with an average config file the parsing on startup requires only nanoseconds so tinyproxy is for all means instantly "ready". if you have a filterlist of thousands of entries, then it might take a little longer.

[Oppen]

The purpose of readiness signaling is to allow proper dependency tracking for service managers.

[Oppen]

Re: quickstart guide: the only option I see there is the one for not daemonizing, which I reformatted as strike through because I later noticed it was there. But the other ones aren't. In particular there's some value in dropping privileges before launching the program, since this avoids running the parser before that (often error prone).

[rofl0r]

the QS guide uses foreground mode/stdout logging/no pid files/restricted user account which are all best practices for daemontools and simple systemd services. if you already start as restricted user, there's no value to be gained from dropping privileges. as for the parsing you mentioned, on SIGUSR1 tinyproxy reloads the config file, so it has to be able to parse even after it's up. i also worked together with distro people (e.g. debian) to modernize their crufty service scripts.

[Oppen]

The point with starting without privileges is precisely not needing to do it after parsing. daemontools/systemd pass sockets so only the socket opening needs privileges, which is done before forking from systemd or exec'ing from the run script in daemontools. That doesn't mean tinyproxy should never parse (it would be a really impractical tool otherwise), but just that this allows doing it only after privileges are dropped since it doesn't need to open the ports itself. Tbh with or without my suggestions this project seems to be the closest to what I want. If you're not interested in the changes I think it would be OK to close the issue.

[rofl0r]

alright then.