This is what just has happened:
And this is what lsof says about it:
root@disp:~ # lsof | grep 58636
Then after some ten minutes the umount succeeds and processing goes on. That happened exactly when some other build was done with exporting from the git repo, so I obviousely thought some flaw is in my locking code. But I now analyzed every detail of the logfiles, and all is correct. There CANNOT have been a process running in the tmp.2.58636 mountpoint at that time - unless git would have started it on it's own and left lingering in background after exiting.
It wouldn't seriously harm. One can see that the code does cope with it and just waits until these go away. But I consider that impolite behaviour, and yet another case of "unsolicited AI interference".
What I am doing at that point, is, the ports are built within temporary bhyve guests. Then, if a port brings a new option, that might be queried in dialogue, but I'm storing the port options within the git repo. So these newly set options must be brought out of the temporary guest and back into the persistent git repo - and keep the same commit number, so that it can always be compared to the commit number stored within the port itself, and one can check with git_diff if a port is up-to-date.
So this part is where the git_bundle that is sent from the bhyve guest gets stored into the persistent repo. Here is the code.
Code:
From /var/sysup/mnt/tmp.1.58636/tmp/vb/Bundle
* branch HEAD -> FETCH_HEAD
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Updated tag 'local.tmp.210704193524' (was 028258d2eb88)
Already on 'local.generic'
Your branch is ahead of 'origin/2021Q3' by 76 commits.
(use "git push" to publish your local commits)
fatal: Not possible to fast-forward, aborting.
Merge made by the 'recursive' strategy.
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
.p23b/conf.serv/options/misc_mc/options | 7 ++++---
.p23b/conf.serv/options/security_libgcrypt/options | 6 ++++++
.p23b/conf.serv/options/textproc_expat2/options | 7 ++++---
3 files changed, 14 insertions(+), 6 deletions(-)
create mode 100644 .p23b/conf.serv/options/security_libgcrypt/options
Updated tag 'local.New' (was 5f8144b4f1a7)
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
umount: unmount of /var/sysup/mnt/tmp.2.58636 failed: Device busy
And this is what lsof says about it:
root@disp:~ # lsof | grep 58636
Code:
lsof: WARNING: compiled for FreeBSD release 12.2-RELEASE-p6; this is 12.2-RELEASE-p9.
sh 58636 root cwd VDIR 2358711076,3064651430 58 4 /var/tmp
sh 58636 root rtd VDIR 0,177 512 2 /
sh 58636 root 0u VCHR 1,113 0t201912 369 /dev/pts/12
sh 58636 root 1u VCHR 1,113 0t201912 369 /dev/pts/12
sh 58636 root 2u VCHR 1,113 0t201912 369 /dev/pts/12
sh 58636 root 10r VREG 61102885,3641695756 8815 67820 /ext/sbin/sysup
git 69889 root cwd VDIR 2173401926,1786895908 83 34 /var/sysup/repo.ports (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
git 69889 root 2u VREG 2173401926,1786895908 0 84453 /var/sysup/repo.ports (build/sysup/repo.ports) (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
git 69889 root 3u VREG 2173401926,1786895908 0 84453 /var/sysup/repo.ports (build/sysup/repo.ports) (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
git 70114 root cwd VDIR 2173401926,1786895908 83 34 /var/sysup/repo.ports (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
git 70114 root 2u VREG 2173401926,1786895908 0 84453 /var/sysup/repo.ports (build/sysup/repo.ports) (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
git 70114 root 3r VDIR 2173401926,1786895908 4 248804 /var/sysup/repo.ports/.git/objects/00 (nullfs /var/sysup/repo.ports on /var/sysup/mnt/tmp.2.58636 (0,0))
Then after some ten minutes the umount succeeds and processing goes on. That happened exactly when some other build was done with exporting from the git repo, so I obviousely thought some flaw is in my locking code. But I now analyzed every detail of the logfiles, and all is correct. There CANNOT have been a process running in the tmp.2.58636 mountpoint at that time - unless git would have started it on it's own and left lingering in background after exiting.
It wouldn't seriously harm. One can see that the code does cope with it and just waits until these go away. But I consider that impolite behaviour, and yet another case of "unsolicited AI interference".
What I am doing at that point, is, the ports are built within temporary bhyve guests. Then, if a port brings a new option, that might be queried in dialogue, but I'm storing the port options within the git repo. So these newly set options must be brought out of the temporary guest and back into the persistent git repo - and keep the same commit number, so that it can always be compared to the commit number stored within the port itself, and one can check with git_diff if a port is up-to-date.
So this part is where the git_bundle that is sent from the bhyve guest gets stored into the persistent repo. Here is the code.