<div dir="ltr">According to <a href="http://libguestfs.org/guestfs.3.html#guestfs_sync">http://libguestfs.org/guestfs.3.html#guestfs_sync</a><div><br></div><div>"You should always call this if you have modified a disk image, before closing the handle."<br></div><div><br></div><div>So, I think '<span style="color:rgb(0,0,0)">guestfish --remote sync</span>' is required because changes made on the disk (<span style="color:rgb(0,0,0)">guestfish --remote rm /tail) should be visible to virt-tail which works in different process and also accessing the same disk.</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--<br> Nikolay Ivanets<br> Mobile: +380979184774<br> Skype: n_ivanets<br></div></div></div></div> <br><div class="gmail_quote">2018-01-03 9:06 GMT+02:00 Nikolay Ivanets <span dir="ltr"><<a href="mailto:stenavin@gmail.com" target="_blank">stenavin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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" target="_blank">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" target="_blank">https://github.com/<wbr>libguestfs/libguestfs/blob/<wbr>master/lib/launch-direct.c#<wbr>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="m_-194243665810202971gmail_signature"><div dir="ltr"><div>--<br> Nikolay Ivanets<br> Mobile: <a href="tel:097%20918%204774" value="+380979184774" target="_blank">+380979184774</a><br> Skype: n_ivanets<br></div></div></div></div> </div></div> </blockquote></div><br></div>