Issue #387: kojid errors when kernel shows deleted mounts in chroot - koji

koji

#387 kojid errors when kernel shows deleted mounts in chroot

Closed: Fixed Apr 27, 2018 Opened Apr 24, 2017 by mikem.

Here is an example traceback

/usr/sbin/kojid:131 [ERROR] Traceback (most recent call last):
  File "/usr/sbin/kojid", line 114, in main
    tm.updateBuildroots()
  File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 597, in updateBuildroots
    if topdir and safe_rmtree(topdir, unmount=True, strict=False) != 0:
  File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 69, in safe_rmtree
    umount_all(path)
  File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 58, in umount_all
    raise koji.GenericError, 'umount failed (exit code %r) for %s' % (rv,path)
GenericError: umount failed (exit code 32) for /mnt/build/mock/rhel-7.4-build-3229142-1918087/root/proc/filesystems\040(deleted)

The actual mount point here is that string without the \040(deleted) which is there because the kernel shows it in /proc/mounts. This is on a builder running RHEL7. The data is coming from the scan_mounts() call.

I'm not sure if we should massage the data from /proc/mounts, or look at another data source here. The \40 seems suspect here.

tkopecek commented Apr 28, 2017

\040 is standard kernel encoding here (oct encoding of " \t\n\", so parsing this string in scan_mounts would be easy). Question is what to do in such case. Just skip the umount of already deleted staled path?

mikem commented Apr 28, 2017

When I've fixed this manually, I've umounted the stale mount

tkopecek commented May 2, 2017

What about #402 ?

mikem commented May 17, 2017

Commit 17a646b6 fixes this issue

tkopecek commented May 17, 2017

Commit 32fa7f04 relates to this ticket

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.13

Jun 20, 2017

Metadata Update from @mikem:
- Issue set to the milestone: 1.16 (was: 1.13)
- Issue status updated to: Open (was: Closed)

Feb 12, 2018