<div dir="ltr">From IRC channel:<div><br></div><div><div><StenaviN> Can someone confirm cat/test-virt-tail.sh works in 'master'?</div><div><StenaviN> I get <a href="https://pastebin.com/GBkg7Vtw">https://pastebin.com/GBkg7Vtw</a></div><div><rwmjones> StenaviN: yes it works for me; the error is not very helpful, you'll need to set LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1</div><div><StenaviN> <a href="https://pastebin.com/yABgCHwV">https://pastebin.com/yABgCHwV</a></div><div><rwmjones> I think the error is:</div><div><rwmjones> libguestfs: trace: statns "/tail"</div><div><rwmjones> guestfsd: => mount_options (0x4a) took 0.00 secs</div><div><rwmjones> guestfsd: <= statns (0x1a5) request length 52 bytes</div><div><rwmjones> [    0.930738] EXT2-fs (sda1): error: ext2_lookup: deleted inode referenced: 12</div><div><rwmjones> guestfsd: error: /tail: Input/output error</div><div><rwmjones> but I don't know exactly why</div><div><StenaviN> Yes, I see. Trying to figure out...</div><div><rwmjones> actually no, that's not the problem</div><div><rwmjones> for some reason two instances of ‘guestfish --remote exit’ run at the same time, but according to the test script only one should run</div><div><rwmjones> notice how the cleanup() function is called twice</div><div><rwmjones> afaik that should never happen</div><div><StenaviN> and I saw two qemu/guestfish processes running. Continue investigating...</div><div><br></div><div>And here is what I found:</div><div><br></div><div><div>Second copy of 'guestfish --listen' process is a child "recovery process" (<a href="https://github.com/libguestfs/libguestfs/blob/master/lib/launch-direct.c#L777">https://github.com/libguestfs/libguestfs/blob/master/lib/launch-direct.c#L777</a>) and that is OK.</div><div><br></div><div>'cleanup' was called twice because:</div><div>1. call to virt-tail returns non-zero exit code (due to Input/Output error. About this later.) and we trap ERR signal which cause to run 'cleanup' once</div><div>2. in 'cleanup' we do 'exit $statuscode' and we trap EXIT and 'cleanup' is called once again</div><div>It might look confusing but not end of the life. At least there is an explanation if I didn't miss something.</div><div><br></div><div>Now about failing test case with virt-tail.</div><div>Jumping ahead, adding extra 'guestfish --remote sync' after 'guestfish --remote rm /tail' in 'cat/test-virt-tail.sh' fixes the test case.</div><div>virt-tail re-creates overlay image each time it trying to access the file and calls guestfs_statns for the file(s) it watching.</div><div>guestfs_statns in turn returns NULL indicating an error with exit code EIO instead of ENOENT: 'EXT2-fs (sda1): error: ext2_lookup: deleted inode referenced: 12'. (see pastebin posted in discussion above).</div><div><br></div><div>So I suspect that changes on original disk made through 'guestfish --remote rm /tail' call were not fully flushed which confirms by proposed patch.</div><div>It is hard to explain why it works on your system but it might be because of number of factors:</div><div>1. Different QEMU caching policy</div><div>2. Different caching policy of underlying OS/filesytem</div><div>3. etc.</div></div><div><br></div><div><div class="gmail_signature"><div dir="ltr"><div>--<br>    Nikolay Ivanets<br>    Mobile: +380979184774<br>    Skype: n_ivanets<br></div></div></div></div>
</div></div>