Lighttpd

Can you avoid the extra calls to time() by setting the default time_t idle_timeout = INT_MAX?
Next, in the periodic jobs section

    if (min_ts != srv->cur_ts) {

    if (min_ts - server_activity > idle_timeout) timed_out = 1;

Lastly, maybe rename server_activity to last_active_ts?

@mackyle: would you review my comments and update the patch? Thanks.

As far as I know, the source of truth for lighttpd is svn://svn.lighttpd.net/lighttpd and the maintainer of that is stbuehler.

I posted this patch because I use it and on the off chance it might be an interesting enhancement to the lighttpd maintainer. It is a rather odd, and it seems to me, somewhat limited use case and so I would not be surprised or upset if it never got picked up.

So, no, I am not inclined to spend any more time on this unless I see some indication from the maintainer that there's interest in picking this up.

I will note, in response to your comments above, that it is entirely incorrect to mix INT_MAX with time_t and any system that has a time() call that is in any way expensive is broken.

If you feel that strongly about the changes, please go ahead and attach an updated patch to this issue with your name on it -- I will not feel offended in any way if your version of the patch should end up getting picked up instead of mine.

"added code to disable if server.max-workers is specified. When server.max-workers is specified in the config file (to a value other than 0), children that exit will just be restarted by the parent."

Good catch. That right there is reason NOT to apply any version of this patch submitted so far.

Having a command-line timeout option that only works sometimes (depending on the config file) is probably a bad idea.
Slightly better would be having the server fail with an error and refuse to start if -i is specified together with max-workers > 0 (which I think is easily addressable).
Even better would be to have -i just work, always.

As for INT_MAX and time_t, what if INT_MAX is 32767, time_t is a (32-bit) long and -i 36000 (ten hours) is requested? It breaks.

The killer application for a -i timeout option is a web server running on-demand using a stream wait inetd configuration with an exit on idle timeout enabled. But lighttpd does not (yet) support an inetd mode. If it did, it would be important that the -i option not be ignored even if a message is emitted to the log file about it.

Having a command-line timeout option that only works sometimes (depending on the config file) is probably a bad idea.
Slightly better would be having the server fail with an error and refuse to start if -i is specified together with max-workers > 0 (which I think is easily addressable).
Even better would be to have -i just work, always.

That could be achieved by having presence of -i override server.max-worker.

However, if launched from inetd, then inetd is listening on IP addresses and port.

Do you have something intermediate that inetd is spawning? If so, that intermediate program could start up lighttpd, if it detected that lighttpd was not running, and then could proxy to lighttpd, which might be listening on a named piped instead of a public inet IP addr. That intermediate program could even implement the idle timeout, allowing it to start lighttpd with whatever server.max-worker setting it desired.

I have not looked at inetd in years, but there is a possibility that someone has already written some of these features into some version of inetd somewhere.

Are you using your patch for anything besides personal use with git instaweb? That use case probably does not need server.max-workers set.