Feature #7939
Updated by Brett Smith over 8 years ago
Today, arv-mount daemonizes very early, before it initializes FUSE or makes any API calls. If those later steps fail, arv-mount will not give the user any indication of that. They'll just see that nothing is actually mounted. Examples of things that can go wrong: * The user doesn't have permission to use FUSE * The user specified @--allow-other@ but @user_allow_other@ is not set in @/etc/fuse.conf@ * The user has a bad Arvados client configuration (wrong API server; invalid API token) * The user tried to mount a collection that they can't read When nothing can be mounted as a consequence of user or administrator error, that error should be reported on stderr, and arv-mount should exit nonzero, so the user immediately knows that there's been a problem, and ideally gets details about what that problem is. For the scope of this story, errors from uncaught exceptions are fine. Obviously we want better error reporting, but that can happen in a later story. We've tried to fix this in the past, but it's non-trivial because our daemonization code closes all file descriptors by default, and FUSE initialization opens @/dev/fuse@, with no apparent API to find the file descriptor it's using. See commit:f573c35a8f. Fix: * Never daemonize (call @self.daemon_ctx.open@) until we're about to call llfuse.main(). * When we construct the DaemonContext, pass @preserve_files=range(3, number of inodes limit)@. Anything arv-mount opens, we trust it to need after daemonization. * Make a users/current API call immediately after parsing command-line arguments. This ensures that Ensure that, in cases where we can make API calls generally. * Write integration tests know we need to simulate each of the above error conditions. It should be possible to just start arv-mount normally and test for open a nonzero exit code. Ensure specific collection, we do that you always unmount no matter what exit code you got. before daemonization.