From owner-freebsd-current Tue Mar 25 23:35:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA23180 for current-outgoing; Tue, 25 Mar 1997 23:35:44 -0800 (PST) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA23168 for ; Tue, 25 Mar 1997 23:35:35 -0800 (PST) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id SAA29314; Wed, 26 Mar 1997 18:35:16 +1100 (EST) From: David Dawes Message-Id: <199703260735.SAA29314@rf900.physics.usyd.edu.au> Subject: Re: SIGTERMs killing X In-Reply-To: from Doug Russell at "Mar 25, 97 07:46:57 pm" To: drussell@saturn-tech.com (Doug Russell) Date: Wed, 26 Mar 1997 18:35:15 +1100 (EST) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >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