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?
On 03/15/2012 03:05 PM, Timo Sirainen wrote:
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?
I don't know that match about systemd. I'll forward this to systemd mailing list and I will let you know once I know more.
On 03/15/2012 03:05 PM, Timo Sirainen wrote:
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?
Seems other projects did not solve this yet. Most projects provide just one service. In that case, they serve any connection they get, because they know what to do.
I've discussed this with systemd upstream and we've decided that the best solution is to log error message and close that socket.
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?
I don't understand this question completely. What it does already is that during start up, when dovecot creates sockets, it checks what sockets already exist and creates only the missing ones.
Systemd provides following functions: sd_is_fifo (3) - Check the type of a file descriptor sd_is_mq (3) - Check the type of a file descriptor sd_is_socket (3) - Check the type of a file descriptor sd_is_socket_inet (3) - Check the type of a file descriptor sd_is_socket_unix (3) - Check the type of a file descriptor sd_listen_fds (3) - Check for file descriptors passed by the init system.
http://0pointer.de/public/systemd-man/sd_listen_fds.html
I wrote simple patch that close the extra sockets. It's tested and works fine. You'll maybe want to move that function to different place and/or change wording of error messages.
Michal
On 16.4.2012, at 12.55, Michal Hlavinka wrote:
I wrote simple patch that close the extra sockets. It's tested and works fine. You'll maybe want to move that function to different place and/or change wording of error messages.
I committed it to v2.1 now with a couple of changes. One is that it doesn't actually close the fd, but instead puts /dev/null into it. I think otherwise Dovecot might use that fd to something else and the check would later fail again and close the wrong fd.
On 05/04/2012 08:54 PM, Timo Sirainen wrote:
On 16.4.2012, at 12.55, Michal Hlavinka wrote:
I wrote simple patch that close the extra sockets. It's tested and works fine. You'll maybe want to move that function to different place and/or change wording of error messages.
I committed it to v2.1 now with a couple of changes. One is that it doesn't actually close the fd, but instead puts /dev/null into it. I think otherwise Dovecot might use that fd to something else and the check would later fail again and close the wrong fd.
Thanks. I tested it, but it does not work because of the ret == 0 check before services_verify_systemd. ret is usually 1
Michal
On 9.5.2012, at 14.49, Michal Hlavinka wrote:
On 05/04/2012 08:54 PM, Timo Sirainen wrote:
On 16.4.2012, at 12.55, Michal Hlavinka wrote:
I wrote simple patch that close the extra sockets. It's tested and works fine. You'll maybe want to move that function to different place and/or change wording of error messages.
I committed it to v2.1 now with a couple of changes. One is that it doesn't actually close the fd, but instead puts /dev/null into it. I think otherwise Dovecot might use that fd to something else and the check would later fail again and close the wrong fd.
Thanks. I tested it, but it does not work because of the ret == 0 check before services_verify_systemd. ret is usually 1
Oh, right. Fixed: http://hg.dovecot.org/dovecot-2.1/rev/17b20880453c
participants (2)
-
Michal Hlavinka
-
Timo Sirainen