Monday 2 February 2009

kmail 'Unknown transport protocol' when sending mail

Ive had an annoying bug with kmail for a few days now, which results in some 'identities' being unable to send mail with the error 'Unknown transport protocol'.

This can happen sporadically, but once it happens you will be unable to send mail until you take steps to fix it.
Theres reports of this error going way back to 2001, and explanations have ranged from a mis-configured firewall, to ISP's blocking non default SMTP servers.
After careful forensic analysis, I can safely say thats a complete crock of shit.

For the record I'm using kmail 1.9.10 on KDE 3.5.10.
I understand the kmail branch has now been frozen, to concentrate on kmail for KDE 4.
I've no idea whether the bug has been carried over into that branch, but since theres been no reports of a workaround so far, it seems likely.

Theres a couple of bugs which lead to this situation.

Firstly, kmail identities appear to require an internal id, which is supposed ot be generated randomly when the identity is first added.
Except the first identity is always added with an internal id of 0, which fails various lookups later in the code. Subsequent identities do get a random ID, which is good stuff.

Quite why its random, Ive no idea. Nor do I know what happens if the random clashes with a previous identity, but I suspect it wont be fun

For this reason, you need to create a placeholder identity, before adding the real ones you want to use. Once you've created the identities, dispose of the placeholder one.

Now to the next bug. After creating an SMTP account, you may later want to change a particular identity to always use this account.
If you later rename the account name, kmail will politely inform you that all identities previously using this account, have been updated to use the renamed account.

There is a bug in the update routine for this, which will result in that identity being unable to send mail. After renaming an SMTP account name, you should then go into the identity, go to Advanced Tab, and then reselect the transport you want to use (ie, the SMTP account name).

Failure to do this will result in the dreaded 'Unknown Transport Protocol', and earlier versions of kmail will also nuke your outgoing mail, giving the impression the mail has actually been sent after all.

Finally, its possible that once you've set up your identities, a chain of events will result in one identities id being reset again, back to 0. This is where the sporadic element comes in, since all of a sudden, a previously working account will no longer be able to send mail.
Ive not yet figured out what causes this, and the only workaround I found was to create a new identity, and the drop the previous. Also check your mail filters after this, since I'm pretty sure any filters I had which referenced the old identity had now disappeared (but I'm not 100% sure on this one)

I hope this helps someone.
I can safely say it drove me utterly bonkers

Memcached fails to set cache entry

I was getting an error in memcached (or rather with memcache PECL extension), saying

PHP Notice: MemcachePool::set() [memcachepool.set]: send of 7861 bytes failed with errno=11 Resource temporarily unavailable
This only occurs when you set a cache entry without compression.
memcache extension 1.3.0 claims to fix this (but only seems to address cache payloads of 32768 bytes), but I found this wasnt the case for shorter data.
Also 1.3.0 requires upgrading to memcached 3.0.2 beta to cope with the new binary protocol.

In the end I had to tweak the tcpip settings in /etc/sysctl.conf, adding the following params

net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.optmem_max = 40960
net.core.netdev_max_backlog = 1024
net.ipv4.tcp_wmem = 65536 131072 262144
net.ipv4.tcp_rmem = 16384 174760 349520
net.ipv4.tcp_mem = 196608 262144 393216

Compilation errors on Ubuntu 8.04

Running ./configure results in error
error: C compiler cannot create executables

Solution: install package libc-dev (actually libc6-dev is current)

Running ./configure results in
error: C++ preprocessor "/lib/cpp" fails sanity check

Solution: gcc may be installed, but g++ isnt. Install package g++

Running ./configure results in
error: X11 libraries not found

Solution: Install libX11-dev, but in the case of kmail at least, this isnt always what it appears.
kmail makefile was firing this error because qt headers werent available.
Install qt3-dev-tools and threaded qt headers from libqt3-mt-dev



Friday 30 January 2009

Compiling lighty with lua for mod_magnet

Compiling mod_magnet for lighttpd requires the lua libraries to be available.
This is pretty easy if you have a package manager installed (yum install lua-devel), but I didnt

Solution:

Grab the latest lua libraries from
http://luabinaries.luaforge.net/download.html

Extract and move the libraries to /usr/local/include and the include files to /usr/local/include

The you need to set some environment variables so lighty knows where they are
export LUA_CFLAGS="-I/usr/local/include -L/usr/local/lib"
export LUA_LIBS="/usr/local/lib"

After that, lighty should compile fine. Be sure to pass --with-lua
./configure --prefix=/usr/local --with-lua

Welcome

This blog is really just a scratchpad for keeping a record of various webdev tasks Ive struggled with in the past

Its not really meant for public reading, although if you happen to land here and you're having a similar problem to one Ive had, drop me a line and I'll see if I can help.