On 9/13/07, Randall R. Schumm <[EMAIL PROTECTED]> wrote:
> I'm having an issue similar to one documented in January
> (http://mail.opensolaris.org/pipermail/zones-discuss/2007-January/006032.html
> ). When a command tries to access a file in the /proc directory of a non
> global zone it hangs, and I'm unable to ^c out of the command.
> Version Info:
> $ uname -a
> SunOS pwy01app03s-fe01 5.10 Generic_118833-24 sun4v sparc
> SUNW,Sun-Fire-T1000
> $ cat /etc/release
>                        Solaris 10 6/06 s10s_u2wos_09a SPARC
>            Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
>                         Use is subject to license terms.
>                              Assembled 09 June 2006
> It seems as any access to a file in the /proc filesystem hangs. Including
> ps, ls, and pgrep. The commands will hang in both the global and non global
> zone. I haven't been able to find any documentation on this, and was hoping
> someone might have a resolution or even explanation.


I am also chasing the same in one of my stations.  In my case, the
problem seems to be specific to a particular user's dovecot process.
Still, the OS should not have allowed that process to hang the
proc-table.  I observed that ps is stuck opening a particular
/proc/<..>/psinfo.  I haven't done any deeper analysis but believe it
could be caused by some locking.

Try the following dtrace script when you run "ps" to catch the specific process.
  dtrace -n 'open*:entry/execname=="ps"/[EMAIL PROTECTED](arg0)] =
sum(timestamp)} tick-5s{trunc(@, 5); printa(@)}'

The reason for the sum(timestamp) is due to the dtrace CPU-wise
collection.  You should be able to match the last few output to ps
with the output from tick-5s.

mdb is able to list out all the processes in my case so mdb is helpful
in seeing which process is causing the problem.

Just me,
Wire ...
Blog: <prstat.blogspot.com>
zones-discuss mailing list

Reply via email to