Quoting Steve Beattie ([EMAIL PROTECTED]): > On Sat, Jul 30, 2005 at 01:18:52PM -0700, Tony Jones wrote: > > # cat /proc/2322/attr/current > > unconstrained (subdomain) > > foobar (foobar) > > > > # ps -Z -p 2322 > > LABEL PID TTY TIME CMD > > unconstrained 2322 ttyS0 00:00:00 bash > > Actually, no, it is the space preceding the open paren that is invalid; > see this patch for the expanded allowed character set in procps 3.2.5: > > > http://cvs.sourceforge.net/viewcvs.py/procps/procps/ps/output.c?r1=1.51&r2=1.52 > > When I discussed this with Albert Cahalan, he *strongly* objected to > allowing whitespace in security contexts, as he felt it would break > scripts that parsed 'ps -Z' output.
Right, I thought this was actually a feature :) This is how ps continues to show expected output under stacker. Given naturally limited space, showing output for multiple modules may not be a good idea. If you want more detail, you go to /proc/pid/attr/current... Clearly this is limiting, but then so is the one line per process you get with ps - "fixing" that is obviously not acceptable. Is there another suggestion for how to handle this, in such a way that ps would show info for >1 module? Is there any example where the current behavior is actually a problem - two modules which it makes sense to stack, which both need to give output under ps? thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
