[lmi] "Device or resource busy" resolves itself?

[Greg Chicares]

Vadim--Do you have any insight into this? I was stuck with
  Device or resource busy
on our corporate redhat server; then, soon after I had begun
to despair, the problem silently resolved itself. I wonder:
 - Is that normal?
 - What should I do if the problem occurs again and doesn't
   go away on its own?

Here are some details. I was running lmi's 'install_redhat.sh'
script, which I hoped would be restartable because the first
thing it does is bulldoze any existing chroot. With 'set -vx',
the logs show:

# First, destroy any chroot left by a prior run.
grep "${CHRTNAME}" /proc/mounts | cut -f2 -d" " | xargs umount || echo "None?"
+ grep lmi_bullseye_1 /proc/mounts
+ cut -f2 '-d '
+ xargs umount
umount: /srv/chroot/lmi_bullseye_1/var/cache/apt/archives: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
umount: /srv/chroot/lmi_bullseye_1/dev/pts: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
+ echo 'None?'
None?
rm -rf /srv/chroot/"${CHRTNAME}"
+ rm -rf /srv/chroot/lmi_bullseye_1
rm: cannot remove '/srv/chroot/lmi_bullseye_1/var/lib/dpkg/info': Directory not 
empty
rm: cannot remove '/srv/chroot/lmi_bullseye_1/var/cache/apt/archives': Device 
or resource busy
rm: cannot remove '/srv/chroot/lmi_bullseye_1/dev/pts/0': Operation not 
permitted
rm: cannot remove '/srv/chroot/lmi_bullseye_1/dev/pts/ptmx': Operation not 
permitted

A previous run had failed while installing numerous packages
in the debian chroot:

  apt-get update
  apt-get --assume-yes install wget g++-mingw-w64 automake libtool make ...

with messages beginning:

  Processing triggers for wine (5.0~rc5-1) ...

  E: Setting in Stop via TCSAFLUSH for stdin failed! - tcsetattr (5: 
Input/output error)
  E: Write error - write (14: Bad address)

(presumably because I had made some mistaken experimental changes
that caused my normal user's home directory not to exist, so that
'wine' couldn't install itself...well, that's my guess)

Anyway, 'jobs' said the script was still running, so I bludgeoned
it with 'kill -9'. Then 'jobs' returned nothing, so I tried the
'rm -rf' and 'umount' commands above manually, but observed the same
error messages as in the log above. Then I did this (not as root):

$lsof /srv/chroot/lmi_bullseye_1/var/cache/apt/archives

and it returned status "1" but printed nothing. My next step
would have been to retry that command, prefixed by "sudo",
and then to try 'fuser' similarly. But before I reached those
steps, I accidentally reran the 'umount' command from zsh
history, and it succeeded--just about five minutes after it
had initially failed.

I'm glad it "worked", but I'm left wondering why. I thought
'kill -9' would terminate the process promptly. Should I have
looked harder for some sort of zombie process? Or could it be
that all the processes I'd started had ended, but some kind
of resource handle persisted for a few minutes and then was
silently released by the OS?