[Dovecot] Hanging IMAP sessions on Mac OS X with dovecot 2.1.10 - worked fine with 2.0.15
Ok, here's a toughie: Out of a whim (and because of the bad weather) I today decided to upgrade my completely functioning 2.0.15 installation on my Mac OS X 10.6.7 system. NB: It's not a Mac OS X Server, as sold by Apple - I have compiled my dovecots myself for quite a while. Anyhow: At first everything appeared to work fine after the upgrade. Up until I created a new user and -while testing- SELECTed his INBOX. The SELECT was stuck. Though the process seemed to be alive I could only get rid of it with a kill -9 pid. The same happened when selecting a newly created mailbox on any of the other (otherwise functioning) accounts, so the problem had nothing to do with the new account, but rather with the fact, that it's INBOX was empty. Using dtruss and gdb I found out, that the dovecot process was trying to obtain a GUID and in the course of doing so invoked gethostbyname(), which intern caused a lot of mach message handling and somewhere, deep down there, the process was stuck. Well, that led my to believe, that there was something wrong with the -so called- mach bootstrap context. I usually start dovecot from with a (home-brewn) startup-script, which invokes it (practically) like so: sudo /usr/libexec/StartupItemContext dovecot (again: all this was working fine under 2.0.15) Now with 2.1.10, when I manually invoke dovecot with just sudo dovecot Everything appears to work fine - at least the sessions don't get stuck any more. But as soon as I logout (with dovecot still running in the background) it loses it's mach bootstrap context and finds itself unable to perform even the simplest tasks, like mapping a username to a uid, etc. pp. -- so starting it without the /usr/libexec/StartupItemContext in the background is out of the question. Now -with all that said- here's my question: What has changed with regards to processual context between 2.0.15 and 2.1.10 when the imap process is spawned/exec'd? Any environmental cleanups, closing of unknown fds, deletion/modification of environment variables, process-group-handlers, etc.? It appears, that the imap process no longer inherits the StartupItemContext from the main process, so some change between 2.0.15 and 2.1.10 must have broken it ... Any help is highly appreciated - Clemens PS: I google'd around a lot and searched the mailing-lists, of course. I only found a post of someone who ran into the same/similar problem dating back to Feb 21st 2012 under the subject dovecot freezes when trying to get mail from maildir with mail, but it was quickly dismissed without ever getting resolved and that was that. PS2: I intentionally didn't include any configs with this mail as they seem to be irrelevant, but of course I can generate the necessary output if needed.
[Dovecot] Update: Hanging IMAP sessions on Mac OS X with dovecot 2.1.10 - worked fine with 2.0.15 (and 2.0.21)
Update: I tried with 2.0.21 and this also works just fine. So it must be something which came in with 2.1.x PS: Where is the documentaion for 2.1.x - i.e. for all the nice additions Timo made? The Website only has 2.0.x, as far as I can tell? (might be wrong here - hadn't touched the whole thing for a while, as my civil life had occupied me :-) Greetings, Clemens
[Dovecot] (vaguely) related to: doveadm auth user ...
While digging through the code I remember having seen something like an (yet undocumented) update_query for SQL (and I guess something similar for the LDAP faction as well)?! Can that be used to augment the doveadm pw function to actually /set/ the password for a given user instead of just calculating the hash, so that an operator can copywaste it into the respective passdb? Just curious ... I guess it would be nice to have doveadm become as central point of administration (yeah, yeah - we would still need a create user and delete user, etc. -- but we would at least be further on our way, wouldn't we? :-) Just 2ยข from Clemens
[Dovecot] (summarized) wishlist :-)
Hello All (and Timo in particular :-) --
While reading through some of the conversations on this list over the past two
weeks or so, I always thought how would this particular problem affect you
and how would you address it in your environment?.
This results in a few suggestions, or thing to wish for, which I thought
others may find useful, hence I'm posting this here.
1) the whole post login scripting is a mighty tool, yet it presently lacks a
few more words in the documentation, i.e., the syntax of the corresponding
config files isn't /entirely/ clear to me. Yes, I can replay the examples
given, but I'm not fully sure, what happens when, etc. I'm perfectly willing,
though, to contribute to that, by documenting findings in the Wiki2 (I'm just
using 2.0.x, sorry). I'd appreciate a few more examples, so if anyone has a
funny, working configuration, making good use of post login scripting, I'd
appreciate it, if you'd show them! :-)
Anyway: A bit more control over PLS would be nice. For example, I'd like to
have a script invoked every time a new session starts (new IMAP/POP3
connection from a unique ID), as many clients open multiple connections at once
and usually I wouldn't want to see the second, third, nth connection - just the
first. Nice would also a post logout scripting feature - again: Both for
all connections, as well as just for the last one. Yes, this certainly
requires a bit more discussion, I know - but I hope to trigger just that with
this message! :-)
2) The local x.x.x.x { feature is very nice, yet it could use some
polishing, I guess. Inclusion of ports and wildcards for either addresses or
ports, for instance. I'm imagining a syntax like this:
local 1.2.3.4 { ... } like now to remain backward compatible
local 1.2.3.4:* { ... } same result, just different new syntax - don't
care about port
local 1.2.3.4:4711 { ... } add port restriction
local *:4711{ ... } don't care for address, but match on port
and -of course- (yes, I am really USING IPv6), the use of
[2001::::] instead of 1.2.3.4 in the examples show above. If
one would like to become really funky, the optional /xx addition to specify a
prefix-length would leave no more wishes open. (Well ... maybe the use of
names derived from DNS instead of literal addresses, of course :-)
[if this feature becomes clearer to me, I'd -again- be happy to help document
it within the Wiki2]
3) The iterate_query in the SQL interface (I assume, there is something
similar in the LDAP realm?) could be supplied with a few (optional, of course)
%x variables, i.e., %s could deliver the service again, like with the
other queries. This could tell the database engine, what the show me all
users query is being used for (quota, expunge, ... basically all functions
of doveadm, where you can supply a -A parameter). A %{env:HOST} could be
used to tell the DB interface, which node of a multi-node installation is
asking. I.e., if you have your users distributed over multiple nodes, each
one might want to perform cleanups only for their own users, saving a lot of
bandwidth for unnecessary NFS traffic, etc.
That's it - for now. Otherwise I'm pretty happy with dovecot, let me make that
very clear here! :-) :-) :-)
Clemens
Re: [Dovecot] IMAP aggregation and MUPDATE protocolo
I'm planning on implementing IMAP client backend for lib-storage, which means you could create namespaces that are proxied to remote IMAP server. Or even make Dovecot act as a caching IMAP proxy for your real IMAP server. Yes, yes --- Y, please!!! :-) Clemens
[Dovecot] multiple IMAP ports, each announcing different capabilities
Hello - is it syntacticly possible to define different imap_capability settings per each inet-listener? I might have to provide a service through a caching proxy sitting in front of dovecot, which might involve restrictions re: the announced imap capabilities. Any hint is highly appreciated! Greetings, Clemens
Re: [Dovecot] multiple IMAP ports, each announcing different capabilities
is it syntacticly possible to define different imap_capability settings
per each inet-listener?
local 10.0.0.1 {
imap_capability = a
}
local 10.0.0.2 {
imap_capability = b
}
Understood. How would that work for different /ports/ (i.e., 143 vs. 10143)?
Thanks again for the quick response
Clemens
[Dovecot] proctitle woes with 2.0.7 vs. 2.0.6
Hello - I just noticed, that there seems to be a change in the way process titles are being set between 2.0.6 and 2.0.7: Behavior of 2.0.6: (ps aux | fgrep dovecot) -- root 30803 0.0 0.0 601540708 ?? S 1:08AM 0:00.00 dovecot/log _dovecot 30802 0.0 0.0 601544624 ?? S 1:08AM 0:00.00 dovecot/anvil root 30801 0.0 0.0 600460472 ?? Ss1:08AM 0:00.01 /usr/local/sbin/dovecot _dovecot 30819 0.0 0.0 607304 1672 ?? S 1:08AM 0:00.01 dovecot/auth [0 wait, 0 passdb, 0 userdb] _dovenul 30818 0.0 0.0 603512 1724 ?? S 1:08AM 0:00.01 dovecot/imap-login [10.11.12.13] root 30805 0.0 0.1 601776 3640 ?? S 1:08AM 0:00.02 dovecot/config Behavior of 2.0.7: -- _dovecot 35104 0.0 0.0 607308 1676 ?? S 1:11AM 0:00.01 dovecot/auth _dovenul 35103 0.0 0.0 603516 1736 ?? S 1:11AM 0:00.01 dovecot/imap-login root 35099 0.0 0.1 601780 3652 ?? S 1:11AM 0:00.02 dovecot/config root 35097 0.0 0.0 601544716 ?? S 1:11AM 0:00.00 dovecot/log _dovecot 35096 0.0 0.0 601552692 ?? S 1:11AM 0:00.00 dovecot/anvil [4 connections] root 35095 0.0 0.0 600464460 ?? Ss1:11AM 0:00.01 /usr/local/sbin/dovecot (of course the configuration remained 100% identical - I just compiled 2.0.7, again using the same ./configure parameters and did a make install) It seems, that while anvil has gained some verbosity, auth and imap-login (and maybe pop-login) seem to have lost their voice. Is there any intention behind this or did I ran into a bug? Greetings from Berlin - Clemens smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] proctitle woes with 2.0.7 vs. 2.0.6
It seems, that while anvil has gained some verbosity, Yes. auth and imap-login (and maybe pop-login) seem to have lost their voice. Is there any intention behind this or did I ran into a bug? Maybe. What OS? Mac OS X 10.6.5 But again: I had just swapped binaries - everything else, including the OS, of course, remained the same. Seeing that anvil can do it I presume, that the process_title_set() routine still works?! Clemens PS: Anything I can do to help test/debug this? smime.p7s Description: S/MIME cryptographic signature
