Version: (using KDE KDE 3.5.0) Installed from: Unlisted Binary Package Compiler: gcc version 3.3.4 Reading specs from /usr/lib/gcc-lib/i586-uhu-linux/3.3.4/specs Configured with: /var/uhubuild/work/compile/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,objc,java,f77,pascal --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --host=i586-uhu-linux Thread model: posix OS: Linux I execute kmail executable, and it has a chance not to start up, if doing so won't show kmail window.
Works fine here. Can you run this: strace -o /tmp/output -f kmail --nofork and attach /tmp/output here?
Now I executed kmail just to chek it will start. It didn't started. And before if it didn't started it didn't started next time until reboot. So I tried to execute strace -o /tmp/output -f kmail --nofork kmail assumes another instance of kmail to run at an another display, if I click to run kmail anyways then no other activity occurs, here is the strace output: http://people.inf.elte.hu/pentek_i/doksik/Linux/bugs/KDE/kmail/strace.txt
According to your trace, KMail hasn't exited: 1663 socket(PF_FILE, SOCK_STREAM, 0) = 3 1663 connect(3, {sa_family=AF_FILE, path="/tmp/.ICE-unix/dcop1547-1135212853"}, 37) = 0 1663 write(3, "\1\2\1\0006\0\0\0005\0\0\0", 12) = 12 1663 write(3, "\0\0\0\10kmail-2\0\0\0\0\5kded\0\0\0\0\tkwallet"..., 54) = 54 1663 read(3, That means it's waiting for an answer from the dcopserver, possibly from kded/kwallet itself.
Now, it wasn't started, and I executed `ps uxa` after the first attempt to start kmail: imi:~$ ps uxa|grep kmail imi 1540 0.9 3.4 40360 17732 ? Ss 15:12 0:00 kmail imi 1541 0.9 3.5 40360 18220 ? Ss 15:12 0:00 kmail imi 1542 0.8 3.5 40360 18220 ? Ss 15:12 0:00 kmail imi 1543 0.9 3.5 40356 18216 ? Ss 15:12 0:00 kmail imi 1544 0.9 3.5 40356 18216 ? Ss 15:12 0:00 kmail imi 1551 0.0 0.0 0 0 ? Z 15:13 0:00 [kmail] <defunct> imi 1552 0.0 1.9 40360 10016 ? S 15:13 0:00 kmail imi 1553 1.2 3.3 46492 17172 ? S 15:13 0:00 kmail imi 1554 0.0 0.0 0 0 ? Z 15:13 0:00 [kmail] <defunct> imi 1555 0.0 0.0 0 0 ? Z 15:13 0:00 [kmail] <defunct> imi 1602 0.0 0.1 4680 636 pts/0 R+ 15:13 0:00 grep kmail imi:~$
This bug still stands for kmail 1.9.1 (kde 3.5.1)
Still present in 1.9.3 kde 3.5.3.
The reason for this is that the first instance of kmail wasn't started properly. Unfortunately, this happens sometimes when kmail is started by the session manager resp. if kmail is started by another application (e.g. by the KOrganizer reminder daemon, Konversation, Kopete, etc.) due to usage of an IMAP ressource. Most likely it's due to some deadlock situation, i.e. kmail is waiting for some other process and the other process waits for kmail (or something more complicated). The workaround for the problem is to issue a 'killall kmail'. All running kmail instances will be safely shutdown and then you can start a new instance. The workaround I'm using in order to prevent this situation in the first place is to exit Kopete, Konversation and KMail/Kontact before logging out of KDE. Moreover, I disabled automatic startup of the reminder daemon on login.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.