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

[Matt]

On Wed, May 7, 2008 at 9:53 AM, Matt <datahead4 at gmail.com> wrote:
> 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
>
Darn it - bad paste.  Trying again:
[mtosto at mtosto-bsd ~]$ ps -axlH | grep vfs
 1000  4019     1   0  46  0  6324  2412 uwait  Is    ??    0:00.00
/usr/local/libexec//gvfs-fuse-daemon /home/mtosto/.gvfs
 1000  4019     1   0  44  0  6324  2412 fu_msg Is    ??    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).
>  >  >
>  >
>  >
>