Date: Thu, 9 Feb 2006 13:54:52 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Jens Trzaska <jt@barfoos.de> Cc: freebsd-stable@freebsd.org, David Kirchner <dpk@dpk.net> Subject: Re: truss and /sbin/init Message-ID: <20060209135452.GA17228@walton.maths.tcd.ie> In-Reply-To: <20060209122530.GA36749@anastasia.lan.barfoos.de> References: <20060208152546.GA78035@anastasia.lan.barfoos.de> <35c231bf0602080751p6df719f0sf61cee25d3404a8@mail.gmail.com> <20060209122530.GA36749@anastasia.lan.barfoos.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 09, 2006 at 01:25:30PM +0100, Jens Trzaska wrote: > Does you or perhaps someone else know why init is locked in core? Its > not the case in 4.x and I can't see why a regular userspace process > is locked. > Can someone explain that? The 'L' flag in ps output corresponds to either the process being locked or it being a system process. In this case, init counts as a system process. It might be worth updating the documentation to make this clearer. Procfs only makes certain nodes available if it thinks you are permitted to debug the process. This includes the mem file. The way it chooses is: (p->p_flag & P_SYSTEM) == 0 && p_candebug(td, p) == 0 (This is in sys/fs/procfs/procfs.c - see the function procfs_candebug) I'm not sure why it rejects system processes explicitly - I think the p_candebug call should be enough, but maybe I've missed something. I'd suggest that you replace the test above with: p_candebug(td, p) == 0 then recompile and reinstall your procfs module. David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060209135452.GA17228>