FreeBSD Port: fusefs-libs-2.7.2_1 - gvfs-fuse-daemon process(es) stuck

[Matt]

On Wed, May 7, 2008 at 9:48 AM, Robert Noland <rnoland at 2hip.net> wrote:
> On Wed, 2008-05-07 at 07:30 -0700, Jeremy Chadwick wrote:
>  > On Wed, May 07, 2008 at 09:19:24AM -0500, Matt wrote:
>  > > Sorry - should have been more specific than the generic "stuck"
>  > > description.  Top shows the process state as "fu_msg" and it is not
>  > > consuming any processor resources, just seemingly sits there idling.
>  > > Output from ps is:
>  > >
>  > >   UID   PID  PPID CPU PRI NI   VSZ   RSS MWCHAN STAT  TT       TIME COMMAND
>  > >  1000  4019     1   0  44  0  6324  2528 -      Ts    ??    0:00.00
>  > > /usr/local/libexec//gvfs-fuse-daemon /home/mtosto
>  >
>  > The "T" flag under State says that the process is stopped.  It's as if
>  > the process was running in the foreground, and was ^Z'd -- same
>  > behaviour.
>
>  I don't want to state the obvious, but attaching to the process with gdb
>  will produce the stopped state.  Was this ps snap taken before or after
>  attaching with gdb?
>
My fault - bad order of info gathering.  Here's a ps snap after
sending the process -CONT signal:

[mtosto at mtosto-bsd ~]$ ps -axlH | grep vfs
 1000  4019     1   0  46  0  6324  2412 uwait  Ts    ??    0:00.00
/usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs
 1000  4019     1   0  44  0  6324  2412 -      Ts    ??    0:00.00
/usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs

>  robert.
>
>
>
>  > The part which confuses me (I'm sure others can explain this part) is
>  > that the parent PID is 1, which is init.  This would indicate that the
>  > process is actually a zombie whose parent has been killed off, and the
>  > child's parent has been assigned to init.
>  >
>  > You might try doing a "kill -CONT" on the process to see what happens.
>  >
>  > I don't think truss or ktrace are going to help here, because something
>  > is explicitly stopping the process (SIGSTOP or some other means).
>  >
>
>