On Tue, Apr 08, 2025 at 08:43:00AM +0200, Jan Stary wrote: > Right, "fstat /home" just treats /home as a named file arg > (which is not "open" by anything).
Thanks all for the thoughts on this problem. I can discuss some of the troubleshooting issues mentioned, unfortunately with no relief for the issue: There is no X server running on the two machines where I am encountering this problem, nor any X-forwarded apps running on them and displaying elsewhere. These machines are little headless servers sitting in a cabinet, and when I want to do a backup, I walk up to them and plug in the backup drive. The idea that the script could be setting its own working directory to the drive it is trying to unmount is one I'll follow up on. However, I don't think this is the full story. The script dies after failing to unmount the drive, and even after that (after the script and all of its processes are long gone), you still get "Device busy" when you try to unmount the drive manually. (Even if your own working dir is /). df shows no volume mounted to any mount point on the drive I'm trying to unmount. I've invoked fstat in every way I can think to do it, but the most comprehensive way I know seems to be running it with no arguments and inspecting its output in less or similar. If I do that, I can find no process using any file on the mounted volume nor any process using it (or any subdirectory) as a working directory. Still, in the case that fstat -f behaves differently to regular fstat: saying fstat -f /my_backup_mount_point shows no processes. The fuser -c command also looks like it would be ideal for investigating this problem, but it shows no processes either. For now I've set up my backup script to sync, sleep for a bit, then use umount -f. It seems brash to ask, but is there a chance that there could be a bug elsewhere in the system? Thanks, --T
