On Fri, Jul 23, 2010 at 9:41 PM, Bruno Wolff III <[email protected]> wrote: > It looks like it can cause problems in the general case, but I think where > it isn't expected that outside processes will be using stuff, as is the > case for livecd creator, it shouldn't hurt.
It doesn't hurt in the general case for livecd-creator, and from my testing allows livecd-creator to clean up after it's self properly when exceptions sprout up from deeper within buildTransaction() which causes the domino effect, and finally also causes livecd-creator to not be able to clean up properly. > Do you know if the issue is umounting in the wrong order or missing umounts? > I would expect this patch to fix umounting stuff in the wrong order, but > if a umount is missed, then I wouldn't expect the umount to succeed without > manual intervention. That would be no worse than today, but wouldn't be > a big help either. No. livecd-creator does everything in the correct order, at the correct times except when exceptions bubble up from deep within buildTransaction(). cleanup() in livecd-creator already works fine, until something deeper causes an exception which with Python and livecd-creator holding on to filedescriptors until it exits, cannot unmount when it catches those exceptions because the filesystem is busy. Using the lazy umount fixes the problem that livecd-creator cannot clean up properly when it runs into a problem, and this maybe the only way to handle this scenario properly for umount/cleanup. -- livecd mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/livecd
