Stipe,
ok, so you assume that on any event of this last ERROR of your log the file handle would be keept in the resource pool, right?
It looks that way. I've got Apache logging out the REMOTE_PORT and a nasty shell script I wrote to print out the CLOSE_WAIT ports. I found one 'event' that I could tie between the two. Here are the appropriate lines from Apache and Kannel.
[12:20:11] [xx.xx.xx.xxx:48680] [xxx wap1] [-] [302 0b 0s] [GET http://xxx.xxx.xxx/xxx/redirect.php?url=www.erowid.com HTTP/1.1]
2005-03-01 12:20:11 [4403] [7] INFO: Fetching URL <http://xxx.xxx.xxx/xxx/redirect.php?url=www.erowid.com> for MSISDN <>
2005-03-01 12:20:12 [19506] [6] INFO: WTP_RESP: resp_machine_find_or_create: ack received, yet having no machine
So essentially the request came in and hit Apache. Apache did the request which was a 302 (redirect). This seems to have caused an ack error of some sort, and the port was not closed. The other ports I've found I could not correlate to an Apache log line. (I tried to do so with another 2-3 stuck CLOSE_WAITs.) So it looks as if these 'unable to decode PDU' errors and such still open a (sometimes un-used) connection to Apache which is never closed.
@Jonathan: if this is reproducable, in terms of: there is a deterministric connection between the corrupt WTP PDUs and the file handle leak, please file it as a bug report to mantis http://bugs.kannel.org/.
I can't be 100% sure as it's tough to correlate things (as I'm sure you know already). I'll file a bug report nonetheless.
Jon
