[kde-linux] Problem with kmail at startup

[Duncan]

tonyb posted on Tue, 09 Feb 2010 09:44:11 +0000 as excerpted:

> Suse 11.2
> KMail Version 1.12.2
> Using KDE 4.3.1 (KDE 4.3.1) "release 6"
> 
> I have two userids which I use, both of which are set (using System
> Settings/Advanced/Autostart) to run kmail on login. On one of the
> userids, kmail (usually) starts okay, on the other, it doesn't. I've
> also tried, on the failing userid, starting kmail from my
> ~/.kde4/Autostart folder; if I do that, I just get the message 'Kmail
> got signal 1; exiting' (or something like that). Is there any file I can
> look at to get more information about what may be happening?

Just so you know, kde 4.3.1 is a bit old.  There were 4.3.2 thru 4.3.5 
updates (the last of which just came out a week or so ago), and 4.4.0 is 
due out today (Feb. 9th).  At present, there's enough bugs still left in 
kde4, and enough of them fixed at each update (particularly the 4.x 
updates like the 4.4.0 that's due out today) that it's generally quite 
well worth doing the upgrades when they're available.  Tho you'll have to 
add a repo and update from there, for distributions that don't make the 
updates available in their main repository.

Meanwhile...

That one user is working and the other not is an important clue.  It's not 
the system install, but rather, something screwed up with the one user's 
config, or kmail storage.

Signal 1 is SIGHUP, hangup, normally received by a an app when the login 
session (terminal or etc) it's running on logs out.  (FWIW the kill 
manpage (man kill in a konsole window) has a nice list of the signal 
names, the numbers associated with them, what the normal result of the 
signal is, and comments.  Some useful ones to know are SIGHUP/1, SIGINT/2 
(interrupt, in command line terminal mode, sent to the foreground app if 
you press control-C), SIGTERM/15 (tell an app nicely to shutdown, giving 
it time to save its work), SIGKILL/9 (cannot be blocked, kills an app 
"with extreme prejudice" as it might be said, use this if other methods to 
kill the app fail), SIGWINCH (no number, normally indicates the size of 
the terminal changed, as when you resize a konsole window), SIGSTOP/
SIGCONT (temporarily suspend an app, continue it once again), and 
SIGSEGV/11 (normally indicates segfault, an app crash, dumps core if you 
have that feature setup for debugging).  SIGPIPE/13 is occasionally seen 
when using pipe redirection, it indicates a broken pipe, and SIGFPE/8 is 
occasionally seen as well, indicating a floating point error, divide by 
zero, commonly.)

The common reason for a SIGHUP is that you're running the app from a shell 
script or the like, or maybe from a terminal window, in the background 
(that one wasn't the case here).  When the script (or konsole window) 
terminates, everything running from it will normally also terminate.

Here's what I do here.  I don't bother with autostart.  I simply have 
kde's session management (in "the application formerly known as kcontrol", 
now too generically to be useful identified as system settings, advanced 
user settings, session manager) set to restore the previous session.  
Then, since kmail is always running in the system tray, it's always 
running when I quit kde, and always restored as part of the session I quit 
with, when I restart kde.  No autostart necessary as it's simply part of 
my normal kde session. =:^)  And if for some reason I'm doing something 
and do shutdown kmail and forget to restart it before I quit kde, so it's 
not started automatically when I restart kde, it's easy enough to hit my 
krunner trigger (I have a keyboard with 'extra' keys here, and have one 
set to krunner, but it's the alt-F2 shortcut by default), type in kmail, 
and away I go.  It's then left running when I shutdown kde again, so it 
again starts as part of the kde session when I next start kde.

Alternatively, try a script like this:

kmail &		# & starts the command in the background
sleep 5		# wait 5 seconds to give it time to get going
disown -a	# disown all, SIGHUP should no longer kill it
exit 0		# this one's optional, you can simply end the script

Another simpler alternative, simply "exec" kmail, which says to run it in 
the same process as the script was running, thereby replacing the script, 
like so:

exec kmail

Whichever of those you try, create a text file with the appropriate lines, 
stick it in the autostart dir, and change the permissions so it's 
executable.  That /should/ do it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman