Does git launch independent asynchronous processes on it's own behalf?

This is what just has happened:
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.
 
Back
Top