It’s always a bit of a gamble when you start playing "Process Assassin" with fuser -mv. One minute you’re trying to unmount a drive, and the next, you’ve accidentally terminated a session that actually mattered.
I’ve organized your findings below with H2 and H3 headings to make this troubleshooting guide much easier for other DBAs to follow.
Beyond Manual Intervention: Why mount-dbfs.sh Beats fuser
I was not satisfied with using fuser -mv to identify processes causing DBFS failure to unmount and killing the processes haphazardly. Upon further investigation, mount-dbfs.sh can be used to kill processes causing "Device or resource busy" and unmount DBFS.
The Hidden Difference in Process Identification
One interesting and important item I have discovered: the process killed from using mount-dbfs.sh is not the same as shown from fuser.
Dissecting the Unmount Failure
Stopping DBFS failed as shown:
oracle@host $ /u02/app/12.1.0/grid/crs/script/mount-dbfs.sh stop unmounting DBFS from /ggdata umounting the filesystem using '/bin/fusermount -u /ggdata' /bin/fusermount: failed to unmount /ggdata: Device or resource busy Stop - stopped, but still mounted, error oracle@host $
Diagnostics: The fuser Perspective
From another session, vi was used to open a file from the DBFS mount (ggdata). Notice the PID for vim is 38331
root@host # fuser -mv /ggdata USER PID ACCESS COMMAND /ggdata: root kernel mount /ggdata ggsuser 2343 ..c.. bash ggsuser 38331 F.c.. vim root@host # exit
Deep Dive: Running the Clean Operation in Debug Mode
Run mount-dbfs.sh clean in debug mode and notice the script targets a completely different process—the dbfs_client itself (PID 27532) rather than the user application.
oracle@host $ /bin/bash -x /u02/app/12.1.0/grid/crs/script/mount-dbfs.sh clean + CONFIG=/etc/oracle/mount-dbfs.conf ... [script logic removed for brevity] ... + logit error 'tried (fusermount -u|umount), still mounted, now cleaning with (fusermount -u -z|umount -f) and kill' + /bin/fusermount -u -z /ggdata ++ /bin/ps -ef ++ /bin/grep -w /ggdata ++ /bin/grep dbfs_client ++ /bin/grep -v grep ++ /bin/awk '{print $2}' + PIDS=27532 + '[' -n 27532 ']' -------------------------------------------------------------------------------- + /bin/kill -9 27532 -------------------------------------------------------------------------------- ++ /bin/ps -ef ++ /bin/grep -w /ggdata ++ /bin/grep mount.dbfs ++ /bin/grep -v grep ++ /bin/awk '{print $2}' + PIDS= + '[' -n '' ']' + exit 1
Script Syntax and Available Parameters
For reference, here are the parameters available for mount-dbfs.sh:
oracle@host $ /u02/app/12.1.0/grid/crs/script/mount-dbfs.sh -h Usage: mount-dbfs.sh { start | stop | check | status | restart | clean | abort | version } oracle@host $
Conclusion: Trusting the Oracle Toolset
In conclusion, it's much better to use the script for what it's designed for versus manually having to identify and kill processes. It handles the dependencies between the FUSE mount and the dbfs_client much more gracefully than a manual kill ever could.
Oracle Database Consulting Services
Ready to optimize your Oracle Database for the future?
.svg){kind=small}
.svg){kind=small}