From owner-freebsd-current@FreeBSD.ORG Mon Dec 15 19:59:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40B7716A4CF; Mon, 15 Dec 2003 19:59:10 -0800 (PST) Received: from smtp8.jp.viruscheck.net (smtp8.jp.viruscheck.net [154.33.69.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id C35AD43D32; Mon, 15 Dec 2003 19:59:07 -0800 (PST) (envelope-from bland@freebsd.org) Received: from scan2.jp.viruscheck.net ([154.33.69.37] helo=mail3.jp.viruscheck.net) by smtp8.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1AW6MO-00035u-00; Tue, 16 Dec 2003 12:59:00 +0900 Received: from [220.220.111.152] (helo=noc.orchid) by mail3.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1AW6MN-00027y-00; Tue, 16 Dec 2003 12:58:59 +0900 Received: from FreeBSD.org (horse.orchid [89.60.10.11]) by noc.orchid (8.12.9p2/8.12.9) with ESMTP id hBG3wv4v080517; Tue, 16 Dec 2003 12:58:58 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <3FDE8301.6030305@FreeBSD.org> Date: Tue, 16 Dec 2003 12:58:57 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Cracauer References: <3EEDD6E2.6040505@mail.ru> <20031215151613.E7304@news1.macomnet.ru> <20031215074942.A59308@cons.org> In-Reply-To: <20031215074942.A59308@cons.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cracauer@FreeBSD.org cc: current@FreeBSD.org cc: bde@FreeBSD.org Subject: Re: truss issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2003 03:59:10 -0000 Martin Cracauer wrote: >[CC'ed Bruce] > >Maxim Konovalov wrote on Mon, Dec 15, 2003 at 03:35:31PM +0300: > > >>Hello, >> >>On Mon, 16 Jun 2003, 23:40+0900, Alexander Nedotsukov wrote: >> >> >> >>>All, >>> >>>I found current truss behaviour a bit strange. It coredumps always if >>>trussed process do without any significant reason for my understanding. >>>I also confused with comment for commit originally introduced this >>>functionality >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/main.c.diff?r1=1.9&r2=1.10. >>>I propose patch attached to make truss always return result of trussed >>>process and do not kill() itself. What do you think about it? >>> >>> >>As a matter of fact, bin/58970 is a backout of rev.1.10 truss/main.c: >> >>---------------------------- >>revision 1.10 >>date: 1998/08/24 10:17:20; author: cracauer; state: Exp; lines: +9 -1 >>When exiting on SIGINT, exit with signal status >>============================================================================= >> >>But a code does not match the comment and does something funny: >> >>@@ -216,6 +217,7 @@ >> break; >> case S_SIG: >> fprintf(outfile, "SIGNAL %lu\n", pfs.val); >>+ sigexit = pfs.val; >> break; >> case S_EXIT: >> fprintf (outfile, "process exit, rval = %lu\n", pfs.val); >>@@ -232,5 +234,11 @@ >> if (ioctl(Procfd, PIOCCONT, val) == -1) >> warn("PIOCCONT"); >> } while (pfs.why != S_EXIT); >>+ if (sigexit) { >>+ if (sigexit == SIGQUIT) >>+ exit(sigexit); >>+ (void) signal(sigexit, SIG_DFL); >>+ (void) kill(getpid(), sigexit); >>+ } >> return 0; >> } >> >>Gentlemen, does anobody know what is going on there? >> >> > >If you catch a signal like SIGINT or SIGTERM (as opposed to leaving >the original OS handler to handle it), then you need to reissue that >same signal to yourself when after your did whatever cleanup you >want. > >The general reason is that the parent of the process needs to be >informed that you exited on a signal. > >The specific reason is that if you don't, then a shellscript will not >be interruptable with SIGINT or SIGTERM. > >I have a lengthly web page about it at > http://www.cons.org/cracauer/sigint.html > > Ah. I must be thinking on it. Thanks! As an excuse for this noise I made I would say that truss is still not ready to be used in batch jobs. Besides it's important to properly respond to SIGINT/QUIT it's not less vital to passthrough child ret codes. Since we always have 0 I wasn't thinking on truss as transparent wrapper. > >As for for problem with the coredumps, I assume this is when SIGQUIT >is used? The proper way of handling this would be to change truss (and >other transparent wrappers) to ulimit the coredump size to zero and >then reissue the SIGQUIT signal. > > No it is not. In fact the code you added forces turss exit(3) with status 3 on SIGQUIT in child. Current implementation does suicide in all but one (SIGQUIT) cases it child does not only upon SIGTERM or SIGQUIT as you suggested on web page. Count on SIGABRT, SIGBUS, SIGILL, SIGSEGV etc. and here we get useless truss.core files. That was my point. Alexander. >But the integrety towards the parent needs to be maintained, you must >not exit without a signal exit status or you get runaway scripts. > >Martin > >