Version: 1.7.2 (using KDE 3.3.2, (3.1)) Compiler: gcc version 3.3.5 (Debian 1:3.3.5-12) OS: Linux (i686) release 2.6.8 After exiting kmail with File/Exit option from menu, the imap client process (kdeinit: kio_newimap4 newimap) stays alive and running in spite of it is not necessary anymore. Apart from some unnecessary ram and cpu usage, there is more important problem which made me to fill this bug: if imap client goes wild for some reason (there are some bugs in it unfortunately), even if one exits kmail and runs it again, the same imap client is reused and the problem stays. To recover one needs to exit kmail, start shell, do sth like ps waux | grep imap, kill found process and then start kmail. Troublesome.
KIOSlaves continue running after the app has quit, by design. They quit after some time of inactivity. So this is no bug. Reopen if your kio_newimap4 slave keeps on running for more than a few minutes after kmail has quit.
Yes, it disappears after a few minutes. But I am still unhappy, procedure: "in case your kmail IMAP handler starts to misbehave, exit kmail, wait for 5 minutes and then start kmail" does not look very nice. Maybe the desing which require kioslaves to run after the app has quit could be adapted at least for the case when slaves misbehaved or reported errors just before the exit - in such case killing them immediately.
If the slave misbehaved, it can't be expected to follow a command such as "quit now". If it reported an error from the server, but is working fine, why should it quit? For that matter, why would you quit KMail at all? There's nothing wrong. Instead, please let us know of any bugs you find in the ioslave so that we can fix it. File one (new) bug report per issue you find, please.
I reported some errors regarding IMAP handling (the most annoying - IMAP slave entering permanent 'weird' state when one removed some messages using another IMAP client - has IIRC been FIXED). Nevertheless for the normal KDE user (as me), propagation of the fix between the KDE CVS and the distribution takes 1 year or so, so it is always worth to implement general solutions which reduce the impact of bugs until they are fixed... And, if slave misbehaved so it does not even handle 'quit' command, it surely should be immediately kill-ed - of course the thing to be implemented generally, not only in kmail
That I agree. klauncher should kill slaves that don't respond to commands. Also, slaves should suicide if they detect an impossible condition --- e.g., sent a QUIT command and got a bizarre answer.
yeah, I have run into such troubles too ... my IMAP connection crashes everytime and only restarting kmail (and imap process) helps; however, sometimes I have to kill the processes manually ... if the imap process reports one single error, it (nearly) never recovers and it has to be restarted :-(
Reassigning the bugs of the SMTP, IMAP and POP ioslaves to kdepim-bugs.
Undo autoconfirm.
Not dying in response to errors is by design. Issues need to be handled another way.