Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Mar 1997 18:35:15 +1100 (EST)
From:      David Dawes <dawes@rf900.physics.usyd.edu.au>
To:        drussell@saturn-tech.com (Doug Russell)
Cc:        freebsd-current@freebsd.org
Subject:   Re: SIGTERMs killing X
Message-ID:  <199703260735.SAA29314@rf900.physics.usyd.edu.au>
In-Reply-To: <Pine.BSF.3.95.970325193822.22277B-100000@hobbes.saturn-tech.com> from Doug Russell at "Mar 25, 97 07:46:57 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
>On Tue, 25 Mar 1997, Terry Lambert wrote:
>
>> I'm not sure whether SIGTERM should ever be sent, actually... I guess
>> it can't hurt, considering it's default is to terminate the process.
>
>All this talk of signals reminds me of a (totally) unrelated problem one
>of my machines seems to be having lately.....  My main workstation, which
>usually runs X all the time, has exited on a sig 6 from X a couple times
>in the last few days for no apparent reason.
>
>Mar 24 12:22:23 586quick166 /kernel: pid 218 (XF86_SVGA), uid 0: exited on signal 6
>Mar 25 11:27:22 586quick166 /kernel: pid 7136 (XF86_SVGA), uid 0: exited on signal 6
>
>I can't for the life of me determine why it would have got an ABORT
>signal....  Where would that be coming from?  The machine is just sitting
>there idle (AFAIK, anyway... :)) and when I get home from work, for
>example, it's no longer running X.  

Check the X server's stderr, and it will tell you (a little) more.  By
default, the server traps most signals, cleans up (restores the video
mode back to a text mode) then calls abort(3) to get a core (if the
server's uid == euid), hence the SIGABRT.

David



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703260735.SAA29314>