[systemd-devel] Fwd: dovecot and systemd

[Colin Guthrie]

'Twas brillig, and Michal Hlavinka at 05/04/12 11:26 did gyre and gimble:
> On 03/17/2012 02:19 AM, Lennart Poettering wrote:
>> On Fri, 16.03.12 15:55, Michal Hlavinka (mhlavink at redhat.com) wrote:
>>
>>>>> 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
>>>>
>>>> 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?
>>
>> So here's what I recommend in cases where the configuration file of the
>> service itself and the systemd sockets passed do not match up: honour
>> both. i.e. go through the list of sockets passed and match them up with
>> the configuration as good as possible, but also listen on all sockets
>> which are configured in the config file but not passed and on all
>> sockets passed that are not configured in the config file.
>>
>> This is what we do in CUPS and what I think is a nice approach since it
>> basically means that any user configuration is always taken into
>> account.
> 
> Unfortunately, this can't be used here. CUPS offers only one service, so
> it always know what to expect on any connection. Dovecot, on the other
> hand, provides five services (imap, imaps, pop3, pop3s, managesieve) and
> when it gets connection on port that is not configured in it's config
> files, it can't know what to do with the connection.
> 
> So if the connection comes to extra port, it won't be served. There are
> three possibilities what can happen next:
> 1) just log message that configuration does not match, do nothing
> 2) log message and close socket that listens on port dovecot won't serve
> 3) log message and terminate dovecot
> 
> I think the 2nd option is the best one here. Does systemd provide any
> API to close those sockets?


Can't answer this specific part, but I guess a longer term solution
(that is much more intrusive and arguably one you don't necessarily want
to support) is to split out the different services that dovecot offers
into separate systemd units, each of which can be configured separately
with their own .socket unit (templated or otherwise).

You could then tie them all together into a single "dovecot.target" unit
(which each of the individual units reference in their WantedBy=
directive) which itself is WantedBy multi-user.target

This way you'd know which service you were starting with the socket and
you'd avoid the problem case outlined above.

Obviously this could be quite intrusive, but it might take also offload
some complexity inside dovecot itself which has to effectively manage
these "sub services" manually. I suspect you cannot ditch this
functionality completely in order to support non-systemd systems which
is no doubt still critical, but depending on the code structure, it
might not actually be that hard?

Disclaimer: I've not played with dovecot much, but from what you
describe it sounds somewhat similar to cyrus which I've fought with on a
few occasions... might have to try migrating to dovecot just for giggles :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/