Bug #11994
closed[arv-mount] Do not crash if /sys/fs/fuse/connections is empty
Description
In debian 9 (stretch), due to a systemd-blames-kernel bug, /sys/fs/fuse/connections/ might be empty.
- https://github.com/systemd/systemd/issues/4574 ("closed", wontfix)
- https://bugzilla.kernel.org/show_bug.cgi?id=187421 ("new" since nov 2016)
When this occurs, instead of crashing, arv-mount --unmount and friends should print a warning and try the next best thing.
The current behavior is a crash with a stack trace culminating in:
IOError: [Errno 2] No such file or directory: '/sys/fs/fuse/connections/45/abort'
Related issues
Updated by Peter Amstutz about 7 years ago
Instead of crashing, arv-mount --unmount and friends should print a warning and try the next best thing.
I'm not sure what the next best thing is, probably kill -9 arv-mount
and then try fusermount -u -z
again?
Updated by Tom Clegg about 7 years ago
- Status changed from New to In Progress
- Assigned To set to Tom Clegg
- Target version changed from Arvados Future Sprints to 2017-11-08 Sprint
I'm not sure what the next best thing is, probably
kill -9 arv-mount
and then tryfusermount -u -z
again?
Without the sysfs dir, we can't look up the pid, so I don't think we can send a signal with kill either. So just fall through to "fusermount -u -z" and try again, yes.
Turns out the "ignore ENOENT" code has been there since the beginning of unmount.py, but it didn't work because it was looking for OSError instead of IOError.
11994-no-sysfs-fuse @ 4a8561a37ef5878aefc8c5d8c47898a3879a0fda
Updated by Peter Amstutz about 7 years ago
Tom Clegg wrote:
I'm not sure what the next best thing is, probably
kill -9 arv-mount
and then tryfusermount -u -z
again?Without the sysfs dir, we can't look up the pid, so I don't think we can send a signal with kill either. So just fall through to "fusermount -u -z" and try again, yes.
So you don't want to walk the process table and look for an arv-mount with the target path in its arguments? (yes, sort of joking)
Turns out the "ignore ENOENT" code has been there since the beginning of unmount.py, but it didn't work because it was looking for OSError instead of IOError.
11994-no-sysfs-fuse @ 4a8561a37ef5878aefc8c5d8c47898a3879a0fda
LGTM.
Updated by Anonymous about 7 years ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|commit:d493d06b4b93b87c10c59954e47a18d85db13150.