From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 11 13:13:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1F810656CF for ; Wed, 11 Mar 2009 13:13:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 760698FC31 for ; Wed, 11 Mar 2009 13:13:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1E13546B1A; Wed, 11 Mar 2009 09:13:34 -0400 (EDT) Date: Wed, 11 Mar 2009 13:13:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nate Eldredge In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, vasanth raonaik Subject: Re: Debugging init process. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 13:13:35 -0000 On Tue, 10 Mar 2009, Nate Eldredge wrote: > On Tue, 10 Mar 2009, vasanth raonaik wrote: > >> I need to debug init process. I am not able to attach init to gdb and it >> throws > > As others mentioned, this is explicitly disabled. You could re-enable it by > hacking the kernel, but it could cause other unexpected problems. > > Alternatively, there's always "printf debugging". > > What is wrong with init, that you need to debug it? It's a fairly simple > program that's been around for a long time and should be pretty stable. One specific concern with debugging init is that the ptracing application will intercept all signals destined for the target application, and since signals are used to manage the system run cycle, and init becomes the parent of orphaned processes, this could lead to unexpected side effects. Also, if init exits, your system will panic :-). Last time I mucked with init, I found the best ways to debug it were: (1) Provide a LD_PRELOAD for libc that replaces getpid(), getppid(), and other things to return pid 1. (2) Run init in a jail so that if it exits, the box won't panic. (3) Use tools like ktrace on the actual init, combined with utrace() instrumentation of init so you can track its behavior "in the wild" FYI, if you do want to clear P_SYSTM, one easy way to do that is to attach kgdb to /dev/mem, and directly manipulate the flags on initproc. This comes with some risks, of course. :-) Robert N M Watson Computer Laboratory University of Cambridge