On Tue, 2009-01-06 at 11:57 -0600, Mike Abbott wrote:
Here's how it works. When there are no mail processes, or none
serving fewer than mail_max_connections clients, the master creates a
new mail process pretty much like it does now, but with some new
environment variables (PERSISTENT_MAIL_PROCESS and CONNECTION_ID, and
ADVISE_SET[GU]ID instead of RESTRICT_SET[GU]ID) and a unix-domain
socket connection back to the master. For future clients the master
sends the client socket and a full dump of the environment via that
connection. Persistent mail processes multiplex I/O for their
connected clients and switch the whole environment and the effective
user ID, group ID, and supplemental groups each time.
Interesting. I hadn't thought of the possibility of doing this in ioloop. Eventually, perhaps in Dovecot v1.3, I hope to get rid of this configuration-in-environment and the environment switching can be dropped then.
Also I thought that your patch would only put the same user's connections to the same process. If done like that it possibly wouldn't even need environment switching and at least wouldn't need uid/gid switching. Also since it would be safer it could be done without a specific configuration option.
Perhaps mail_process_per_connection=yes would work like you've done currently and =no would still connect the same user to same processes. Hmm. Actually even with =yes it should try to do that when possible.
- Sending the master process SIGINFO (on platforms that support that
signal) makes it print its view of all the clients connected to all
the mail processes. Sending SIGINFO to an individual mail process
makes it print its view. These are not necessarily always the same.
For instance, on a config reload (SIGHUP), the master disconnects from
the mail processes but leaves them running. The output is admittedly
kinda geeky.
Maybe just SIGUSR2 that's available everywhere?
- The logging tag for a persistent mail process is just "*" instead of
the user name, since a process can serve multiple users. Some
individual messages (such as connect/disconnect) identify the user.
Couldn't this also be done the same way as environment switching?
Actually the context switching details could probably be abstracted out of ioloop and just made into configurable callbacks where imap/pop3 would do the environment/etc. switch.
- The dict client interface is blocking which is unfortunate for
persistent mail processes. The patch does not address this, since the
delay is probably small and we don't use it anyway.
Even if it was non-blocking, its callers would eventually have to block because the calls always(?) come via lib-storage API, which is blocking in most places. Non-blocking lib-storage API would be nice in theory but I haven't figured out how to do it without making the API horrible to use.
And a small implementation issue: mail-processes.c:mail_connections should probably be an array instead of a hash table.