diff options
Diffstat (limited to 'Documentation/public-inbox-daemon.pod')
| -rw-r--r-- | Documentation/public-inbox-daemon.pod | 46 |
1 files changed, 31 insertions, 15 deletions
diff --git a/Documentation/public-inbox-daemon.pod b/Documentation/public-inbox-daemon.pod index 5d26ce56..6f1e3b53 100644 --- a/Documentation/public-inbox-daemon.pod +++ b/Documentation/public-inbox-daemon.pod @@ -31,9 +31,9 @@ processes to take advantage of multiple CPUs. =over -=item -l [PROTO://]ADDRESS[?opt1=val1,opt2=val2] +=item -l [PROTOCOL://]ADDRESS[?opt1=val1,opt2=val2] -=item --listen [PROTO://]ADDRESS[?opt1=val1,opt2=val2] +=item --listen [PROTOCOL://]ADDRESS[?opt1=val1,opt2=val2] This takes an absolute path to a Unix socket or HOST:PORT to listen on. For example, to listen to TCP connections on @@ -101,26 +101,42 @@ Default: 1 The default TLS certificate for HTTPS, IMAPS, NNTPS, POP3S and/or STARTTLS support if the C<cert> option is not given with C<--listen>. -Well-known TCP ports automatically get TLS or STARTTLS support -If using systemd-compatible socket activation and a TCP listener -on port well-known ports (563 is inherited, it is automatically -NNTPS when this option is given. When a listener on port 119 is -inherited and this option is given, it automatically gets -STARTTLS support. +With this option, well-known TCP ports automatically get TLS or STARTTLS +support if using systemd-compatible socket activation. That is, ports +443, 563, 993, and 995 support HTTPS, NNTPS, IMAPS, and POP3S, +respectively; while ports 110, 119, and 143 support STARTTLS on POP3, +NNTP, and IMAP, respectively. =item --key /path/to/key The default TLS certificate key for the default C<--cert> or per-listener C<cert=> option. The private key may be -concatenated into the path used by the cert, in which case this +concatenated into the cert file itself, in which case this option is not needed. +=item --multi-accept INTEGER + +By default, each worker accepts one connection at a time to maximize +fairness and minimize contention across multiple processes on a +shared listen socket. Accepting multiple connections at once may be +useful in constrained deployments with few, heavily loaded workers. +Negative values enables a worker to accept all available clients at +once, possibly starving others in the process. C<-1> behaves like +C<multi_accept yes> in nginx; while C<0> (the default) is +C<multi_accept no> in nginx. Positive values allow +fine-tuning without the runaway behavior of C<-1>. + +This may be specified on a per-listener basis via the C<multi-accept=> +per-listener directive (e.g. C<-l http://127.0.0.1?multi-accept=1>). + +Default: 0 + =back =head1 SIGNALS Most of our signal handling behavior is copied from L<nginx(8)> -and/or L<starman(1)>; so it is possible to reuse common scripts +and/or L<starman(1)>, so it is possible to reuse common scripts for managing them. =over 8 @@ -141,7 +157,7 @@ Reload config files associated with the process. =item SIGTTIN -Increase the number of running workers processes by one. +Increase the number of running worker processes by one. =item SIGTTOU @@ -149,7 +165,7 @@ Decrease the number of running worker processes by one. =item SIGWINCH -Stop all running worker processes. SIGHUP or SIGTTIN +Stop all running worker processes. SIGHUP or SIGTTIN may be used to restart workers. =item SIGQUIT @@ -177,7 +193,7 @@ activation. See L<systemd.socket(5)> and L<sd_listen_fds(3)>. =item PERL_INLINE_DIRECTORY -Pointing this to point to a writable directory enables the use +Pointing this to a writable directory enables the use of L<Inline> and L<Inline::C> extensions which may provide platform-specific performance improvements. Currently, this enables the use of L<vfork(2)> which speeds up subprocess @@ -194,8 +210,8 @@ created by a user. See L<Inline> and L<Inline::C> for more details. There are two ways to upgrade a running process. Users of process management systems with socket activation -(L<systemd(1)> or similar) may rely on multiple instances For -systemd, this means using two (or more) '@' instances for each +(L<systemd(1)> or similar) may rely on multiple daemon instances. +For systemd, this means using two (or more) '@' instances for each service (e.g. C<SERVICENAME@INSTANCE>) as documented in L<systemd.unit(5)>. |