Re: Debugging init process.
Quoting Marius Nünnerich mar...@nuenneri.ch (from Wed, 11 Mar 2009 15:54:44 +0100): On Wed, Mar 11, 2009 at 08:51, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, 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. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). DTrace is not available for userland processes yet. Depending on what is needed (it may not be needed to attach gdb, it may be sufficient to have something like ktrace, the OP didn't specify the problem), DTrace may suit the needs. Bye, Alexander. -- Your true value depends entirely on what you are compared with. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Debugging init process.
Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, 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. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). Bye, Alexander. -- Don't interfere with the stranger's style. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Debugging init process.
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Debugging init process.
On Wed, Mar 11, 2009 at 08:51, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Nate Eldredge neldre...@math.ucsd.edu (from Tue, 10 Mar 2009 19:02:16 -0700 (PDT)): On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, 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. If this is on -current and depending on the problem, dtrace may be an option (I don't know if it special-cases init or not). DTrace is not available for userland processes yet. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Debugging init process.
2009/3/10 vasanth raonaik vasanth.raon...@gmail.com: Hello Team, I need to debug init process. I am not able to attach init to gdb and it throws That is because init is a system process, which you cannot trace by design (see ptrace(2)). $ ps -o flags -p 1 F 10004200 , where from ps(1): P_SYSTEM0x00200 System proc: no sigs, stats or swapping -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Debugging init process.
On Wednesday 11 March 2009 06:43:50 pluknet wrote: 2009/3/10 vasanth raonaik vasanth.raon...@gmail.com: Hello Team, I need to debug init process. I am not able to attach init to gdb and it throws That is because init is a system process, which you cannot trace by design (see ptrace(2)). Interesting, but it doesn't really help him debug it ;) Unless there is some other way around it you can stop the kernel making it a system process by editing /usr/src/sys/kern/init_main.c around line 730 (in create_init). Although some signal code seems to specialcase PID 1 so maybe that won't work either.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Debugging init process.
On Tue, 10 Mar 2009, vasanth raonaik wrote: Hello Team, 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. -- Nate Eldredge neldre...@math.ucsd.edu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
