<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>> That makes no sense because we are supposed to have just forked</div>successfully</div><div dir="ltr"><br></div><div dir="ltr">I just realized libguestfs uses fork. Now we know why qemu-img worked - I launched it with popen.</div><div dir="ltr"><br><div>> So it must be something to do with collectd and how it runs programs.</div>> Is it using LD_PRELOAD trickery, or replacing libc, or using seccomp?</div><div dir="ltr"><br><div>If I understand the question correctly - it's about how collectd loads its plugins? If so it uses:</div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="monospace, monospace">static int plugin_load_file(const char *file, _Bool global) {</font><br></div><div><font face="monospace, monospace"> void (*reg_handle)(void);<br></font></div><div><font face="monospace, monospace"><div> int flags = RTLD_NOW;</div><div> if (global)</div><div> flags |= RTLD_GLOBAL;</div></font></div><div><div><div><div><font face="monospace, monospace"> void *dlh = <b>dlopen</b>(file, flags);</font></div></div></div></div><div><div><div><div><font face="monospace, monospace"> //...</font></div></div></div></div><div><div><div><div><font face="monospace, monospace"> reg_handle = (void (*)(void))<b>dlsym</b>(dlh, "module_register");</font></div></div></div></div><div><div><div><div><font face="monospace, monospace"> //...</font></div></div></div></div><div><div><div><div><font face="monospace, monospace"> <b>(*reg_handle)();</b></font></div></div></div></div><div><font face="monospace, monospace">}</font></div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Does this give any clues?</div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">Best Regards,<br>Peter</div></div></div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 12:56 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 07, 2018 at 12:32:48PM +0200, Peter Dimitrov wrote:<br> > Thank you, Rich,<br> > This was the issue indeed. export LIBGUESTFS_BACKEND=direct fixed it.<br> > <br> > The next step I tried was to integrate libguestfs in collectd virt plugin<br> > to collect this data automatically.<br> > In this case I'm having an unknown error in add_libvirt_dom() (same with<br> > add_domain) when it's invoking qemu-img to create overlay image.<br> > <br> > There is no difference between manual and service execution.<br> > I tried setting LIBGUESTFS_BACKEND to direct,<br> > libvirt, libvirt:qemu:///session with no success.<br> > Also tried using a different tmp dir just in case - nothing.<br> > <br> > Maybe something is wrong with how collectd runs its plugins (dynamic<br> > linking)?<br> > Invoking virt-df from collectd's plugin gives the same error message.<br> > I tried running the same qemu-img command from collectd and it passes<br> > though! Confusing...<br> <br> The log indicates something a bit strange is going on:<br> <br> > libguestfs: command: run: qemu-img<br> > libguestfs: command: run: \ create<br> > libguestfs: command: run: \ -f qcow2<br> > libguestfs: command: run: \ -o<br> > backing_file=/home/peterd/TVE/wer.qcow2,backing_fmt=qcow2<br> > libguestfs: command: run: \ /tmp/libguestfsUIZbDK/overlay1.qcow2<br> > Formatting '/tmp/libguestfsUIZbDK/overlay1.qcow2', fmt=qcow2<br> > size=107374182400 backing_file=/home/peterd/TVE/wer.qcow2 backing_fmt=qcow2<br> > encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16<br> > libguestfs: error: command: waitpid: No child processes<br> > libguestfs: error: qemu-img: /tmp/libguestfsUIZbDK/overlay1.qcow2: qemu-img<br> > exited for an unknown reason (status -1), see debug messages above<br> <br> Obviously waitpid(2) is failing with ECHILD here:<br> <br> <a href="https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L741" rel="noreferrer" target="_blank">https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L741</a><br> <br> That makes no sense because we are supposed to have just forked<br> successfully:<br> <br> <a href="https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L479" rel="noreferrer" target="_blank">https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L479</a><br> <br> called from:<br> <br> <a href="https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L764" rel="noreferrer" target="_blank">https://github.com/libguestfs/libguestfs/blob/3430c2dd654b19a55d213a9302ac5e4b6a387bee/lib/command.c#L764</a><br> <br> Notice also that qemu-img *does* run (you can see the output from the<br> command).<br> <br> So it must be something to do with collectd and how it runs programs.<br> Is it using LD_PRELOAD trickery, or replacing libc, or using seccomp?<br> My guess is that any program which launched a subprocess and then<br> waited for it would fail in the same way.<br> <br> Rich.<br> <br> -- <br> Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br> Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br> virt-df lists disk usage of guests without needing to install any<br> software inside the virtual machine. Supports Linux and Windows.<br> <a href="http://people.redhat.com/~rjones/virt-df/" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones/virt-df/</a><br> </blockquote></div>