On 12/11/17(Sun) 04:36, Helg Bredow wrote:
> On Fri, 10 Nov 2017 11:55:53 +
> Helg Bredow wrote:
>
> > On Fri, 10 Nov 2017 10:13:35 +0100
> > Anton Lindqvist wrote:
> >
> > > On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > > > On 09/11/17(Thu) 09:02, Helg Bredow wrote:
On Fri, 10 Nov 2017 11:55:53 +
Helg Bredow wrote:
> On Fri, 10 Nov 2017 10:13:35 +0100
> Anton Lindqvist wrote:
>
> > On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > > On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > > > The current libfuse signal handling assumes that th
On Fri, 10 Nov 2017 10:13:35 +0100
Anton Lindqvist wrote:
> On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> > On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > > The current libfuse signal handling assumes that the file system will
> > > always be unmounted by the child. One obvi
On Fri, Nov 10, 2017 at 09:36:25AM +0100, Martin Pieuchot wrote:
> On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> > The current libfuse signal handling assumes that the file system will
> > always be unmounted by the child. One obvious case where this is not true
> > is if the file system is busy.
On 09/11/17(Thu) 09:02, Helg Bredow wrote:
> The current libfuse signal handling assumes that the file system will always
> be unmounted by the child. One obvious case where this is not true is if the
> file system is busy. To replicate:
>
> 1. mount a fuse file system
> 2. cd anywhere on the fi
The current libfuse signal handling assumes that the file system will always be
unmounted by the child. One obvious case where this is not true is if the file
system is busy. To replicate:
1. mount a fuse file system
2. cd anywhere on the file system
3. pkill -INT
The result is a zombie child