1 files changed, 84 insertions, 0 deletions
diff --git a/doc/wiki/SocketUnavailable.txt b/doc/wiki/SocketUnavailable.txt
new file mode 100644
index 0000000..b4068bc
--- /dev/null
+++ b/doc/wiki/SocketUnavailable.txt
@@ -0,0 +1,84 @@
+UNIX Socket Resource Temporarily Unavailable
+============================================
+
+Commonly visible as:
+
+---%<-------------------------------------------------------------------------
+imap-login: Error: net_connect_unix(imap) failed: Resource temporarily
+unavailable
+---%<-------------------------------------------------------------------------
+
+This means that there are more imap-login processes trying to connect to the
+"imap" UNIX socket than there are imap processes accepting the connections. The
+kernel's connection listener queue got full and it started rejecting further
+connections. So what can be done about it?
+
+Wrong service settings
+----------------------
+
+This can happen if 'service imap { client_limit } ' is set to anything else
+than 1. IMAP (and POP3 and other mail) processes do disk IO, lock waiting and
+such, so if all the available imap processes are stuck waiting on something,
+they can't accept new connections and they queue up in the kernel. For mail
+processes only 'client_limit=1' is recommended, except maybe for very tiny
+systems with a few users.
+
+It can also happen if 'service imap { process_limit } ' is reached. Dovecot
+logs a warning if process_limit or client_limit is reached.
+
+Out of file descriptors
+-----------------------
+
+If the "ulimit -n" is too low, kernel stops notifying the process about
+incoming connections. Make sure that the limit is at least as high as the
+client_limit. Dovecot also internally checks this, and if it's too low it
+writes a warning to stderr at startup (and to log in v2.2.33+).
+
+Note that Dovecot is not using "dovecot" user's or PAM's limits in general.
+Make sure the limits are correct with:'cat /proc/`pidof dovecot`/limits'
+
+Master process busy
+-------------------
+
+Dovecot master process forks all of the new processes. If it's using 100% CPU,
+it doesn't have time to fork enough new processes. Even if it's not constantly
+using 100% CPU there may be fork bursts where it temporarily gets too busy. The
+solution is to make it do less work by forking less processes:
+
+ * Most importantly switch to <high-performance login process mode>
+   [LoginProcess.txt]. This alone might be enough.
+ * You can also switch (most of the) other commonly forked processes to be
+   reused. For example 'service imap { service_count = 100 } ' reuses the imap
+   process for 100 different IMAP connections before it dies. This is useful
+   mainly for imap, pop3 and managesieve services. It's better to avoid using
+   'service_count=0' (unlimited) in case there are memory leaks.
+ * You can pre-fork some idling processes to handle bursts with 'service {
+   process_min_avail }'.
+
+See <Services.txt> before changing any service settings. Some services require
+specific values to work correctly.
+
+Listener queue size
+-------------------
+
+Dovecot uses the ' service { client_limit } '*' service { process_limit } ' as
+the listener queue size. Dovecot v2.2.25 and older also had a hardcoded maximum
+of 511, while later versions have no upper limit. Most OSes use an even lower
+limit, typically 128. In Linux you can increase this from
+'/proc/sys/net/core/somaxconn'.
+
+Dovecot v2.2.[0-6] bug
+----------------------
+
+Dovecot v2.2.0 - v2.2.6 were attempting to optimize host.domain lookups by
+doing them only once in the master process. Unfortunately they were actually
+doing the lookup every time when creating a new process. In some configuration
+this lookup could have done a somewhat slow DNS lookup, causing the process
+creation to become very slow and triggering this message.
+
+The fix is in v2.2.7 and you can also workaround this:
+
+ * Add to dovecot.conf: 'import_environment = TZ DEBUG_OUTOFMEM
+   DOVECOT_HOSTDOMAIN=mailserver.example.com' (of course changing the value)
+
+(This file was created from the wiki on 2019-06-19 12:42)