This is showing that there is something using the NFS mounted filesystem. This could be a user or scheduled process using this for input or output files or the current working directory. Another alternative would be that there is a sub-mounted filesystem.
Commands such as df | grep patch_mount & fuser -c /path_mount might give you more information about what is in use.
Be aware that deleted files that are still open will still hold the filesystem in-use until their processes end.
fuser, the option -c is not recognized, but shows fuser pc10:/backup/cediback2 processes that are not related (I think) ..
the resource /cediback2 only used for the backup script, other users do not accessed.
The detail of each pid is:
The most likely mistake is that YOU are in a directory on the filesystem when you try to umount. In that situation you cannot umount even if you are root (unless you use the -f (force) switch which is not recommended).
vbe: No returns nothing
# fuser -u /cediback2
/cediback2:
from what I understand the man in nfs specify them as "host: filesystem."
also probe fuser 'fuser /tmp/fileEdited', but does not show me the pid of the process corresponding vi (I must have a conceptual error)
rbatte1: English is not my native language, I can not understand the semantics of "Another alternative would be That there is a sub-mounted filesystem," can you explain me what would be the case?
achenle: the same, "It could be shared Also back out" read the words but can not understand ..
hicksd8: yes, I would think the same .. but I'm not at the time of removal. Also he did not find the process that has "taken" the /cediback2.
SCO In the version I'm using no force umount option (or just do not see it)
I show the steps:
# > pwd
/
# > mount
/ on /dev/root read/write on Fri Aug 08 20:16:30 2014
/stand on /dev/boot read only on Fri Aug 08 20:16:30 2014
/cediback2 on pc10:/backup/cediback2 read/write on Sat Aug 09 07:23:10 2014
# > umount /cediback2
umount: /cediback2 busy: Device busy (error 16)
The directory is only backup, the execution would be as:
umount /cediback2 [sometimes works, sometimes not]
mount /cediback2
backup.sh
umount / cediback2 [sometimes works, sometimes not]
Being rather old-fashioned for a minute, I wonder if you need to:
# sync
# umount /cediback2
sync has been made largely obsolete but I wonder whether the O/S knows that it still has data to write and so won't let the filesystem go.
Just something I would try.
That might explain why sometimes it works and sometimes it doesn't.
One node is SCO, what is the other? O/S? Are the two NFS version the same? Version 2,3 or 4? Perhaps the mount needs to be done with the version switch on the command line.
Also, have you considered that this could be a bug? (possibly with a patch issued to fix.)
Flako, you should upgrade to at least 5.0.6 with RS506a. It will install with your current license, as long as you do not have a Compaq branded license.
5.0.2 is as old as Windows 95, and was obsoleted by SCO in 1999.
vbe:
right now I can not try 'fuser -k' because a 'fuser' show me pid of user processes, but if the solution is to get started to kill processes ...
The computer has only one lan connection.
Corona688:
I think the solution is to get started to kill all processes indicating fuser (complicated I find a schedule that is not with users)
hicksd8
I think it's a bug, I wrote the post if there is anything I see or am doing wrong .. (I need a different view to mine)
The SLED10 supports v2 and v3, and v2 SCO
jgt:
If it is true that the sco is old, but migrating is not so easy ... (we are about to migrate to 5.0.7 with VirtialBox)
When you find the time to kill the process, I comment.
Thanks for writing and for what will come
