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? Michal
On Thu, 2012-03-15 at 14:34 +0100, Michal Hlavinka wrote:> What exactly should happen when > dovecot.conf does not match dovecot.socket configuration?Dovecot's systemd code was written by one of you Redhat guys. I had some similar thoughts when I applied the patch, but didn't really know what to do about it, so I didn't do anything. So: I don't know. Maybe some other project has solved this somehow already? Dovecot anyway needs its own internal UNIX listeners. Should all internal inet listeners be disabled? Could Dovecot somehow talk to systemd and ask what listeners it's using for Dovecot and log warnings if they don't match?
Maybe Matching Threads
- RFC: nut and systemd
- Fix broken systemd integration in the build system
- NUT on openSUSE 12.3 requires additional systemd service unit
- NUT on openSUSE 12.3 requires additional systemd service unit
- NUT on openSUSE 12.3 requires additional systemd service unit