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

[Jeremy Chadwick]

On Wed, May 07, 2008 at 10:22:09AM -0500, Matt wrote:
> 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

Now can you run truss or ktrace on PID 4019?  The previous time you ran
ktrace/truss, the process was suspended and the event name was "-", so
no syscalls seen makes sense.

This may end up being one of those situations where one needs to launch
gvfs-fuse-daemon via "truss -o /tmp/truss.out -f gvfs-fuse-daemon
<args>", to see what it's doing from initial startup to the time it
idles.  -a and -D might also come in handy here.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |