On 03/16/2012 03:55 PM, Michal Hlavinka wrote:
I'm forwarding this to more appropriate mailing list. Can you please
share your thoughts about this topic? Do you know about other projects
that were in the same situation and how did they solved it?
Hi all,
dovecot supports systemd socket activation. Together with standard unit
activation (like old sysv init script), there are two ways how to
configure dovecot(only interface:port, not whole configuration). This
can result in situation where those configurations does not say the
same. Question is what should happen then?
For example, lets have dovecot configured to listen for imap(s) and lets
have systemd dovecot socket configured to listen for all protocols -
pop3(s) and imap(s). When dovecot is configured to start on boot,
systemd will start it and dovecot will listen on imap(s) ports. But when
dovecot.socket is enabled, it'll listen on pop3(s) too and when new pop3
connection comes, it'll pass it to dovecot and dovecot will serve it.
The question is: Should this happen? What exactly should happen when
dovecot.conf does not match dovecot.socket configuration?
Hi,
daemon(7) says "If sockets are passed (i.e. when sd_listen_fds() returns
a positive value), skip the socket creation step and use the passed
sockets.". And sd_listen_fds(3) says "[It] is recommended to verify the
correct socket types before using them. [...] In order to maximize
flexibility it is recommended to make these checks as loose as possible
without allowing incorrect setups. i.e. often the actual port number a
socket is bound to matters little for the service to work, hence it
should not be verified."
I think that this is a sound recommendation -- let systemd.socket
configuration override the configuration in dovecot.conf file. If the
administrator disables dovecot.socket and enables dovecot.service, then
the .service configuration overrides other sources.
If dovecot.conf says that dovecot should listen on say imap port, and
this port is not present in one of the passed descriptors, they it might
make sense to issue a warning, to help catch misconfigurations.
Zbyszek
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
