similar to: [PATCH libnbd] states: connect_command: Don't set O_NONBLOCK on socket passed to child.

On 5/25/19 3:22 PM, Eric Blake wrote: > On 5/25/19 1:33 PM, Richard W.M. Jones wrote: >> I also made the code a bit more robust about closing the socket along >> error paths. >> --- >> generator/states-connect.c | 21 ++++++++++++++++++--- >> 1 file changed, 18 insertions(+), 3 deletions(-) >> > >> assert (!h->sock); >> assert

On 5/25/19 1:33 PM, Richard W.M. Jones wrote: > I also made the code a bit more robust about closing the socket along > error paths. > --- > generator/states-connect.c | 21 ++++++++++++++++++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > assert (!h->sock); > assert (h->argv); > assert (h->argv[0]); > - if (socketpair (AF_UNIX,

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

On Friday 06 February 2015 10:03:37 Richard W.M. Jones wrote: > On Thu, Feb 05, 2015 at 10:53:06PM +0000, Margaret Lewicka wrote: > > Hello, > > > > I'm attempting to create a Homebrew formula to get libguestfs to > > compile on Mac OS X. I've managed to achieve success with several > > monkey patches, but since Homebrew's policy is to contact

As the start of work to add remote support, I'm taking a close look at the protocol layer in the library. These are some small cleanups. Rich.

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

I've been taking a long hard look at the protocol layer. It has evolved over a long time without any particular direction, and the result is, to say the least, not very organized. These patches take a first step at cleaning up the mess by abstracting out socket operations from the rest of the code. The purpose of this is to allow us to slot in a different connection layer under the

On 9/26/19 11:40 AM, Richard W.M. Jones wrote: > This adds new APIs for running a local NBD server and connecting to it > using systemd socket activation (instead of stdin/stdout). > > This includes interop tests against nbdkit and qemu-nbd which I > believe are the only NBD servers supporting socket activation. (If we > find others then we can add more interop tests in

Get the address family from h->connaddr instead. This should make no difference to existing code. --- generator/states-connect.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/states-connect.c b/generator/states-connect.c index 04e894c..d62b0f5 100644 --- a/generator/states-connect.c +++ b/generator/states-connect.c @@ -51,7 +51,8 @@ STATE_MACHINE { int fd;

Hello, I'm attempting to create a Homebrew formula to get libguestfs to compile on Mac OS X. I've managed to achieve success with several monkey patches, but since Homebrew's policy is to contact maintainers about proper fixes in upstream, I would like to ask if there are any plans to fix these issues. I'm afraid I don't know C well enough to propose decent solutions myself.

v1 was discussed here: https://www.redhat.com/archives/libguestfs/2019-October/thread.html#00100 v2: - Bind to VMADDR_CID_ANY (instead of HOST) and update the documentation accordingly. - Don't bother with SOCK_CLOEXEC fallback path that can never be used. Rich.

Try doing: $ nbdsh nbd> h.connect_command (["nbdkit", "-s", "null"]) At this point you may observe your laptop fan starts to spin and nbdkit is consuming 100% of CPU. In all other respects everything works fine, you can send commands etc. Anyway I tracked the issue down. nbdkit sits in a loop continuously reading stdin, each read(2) call returning EAGAIN.

A prior patch highlighted the following leak: when any construction step fails in the parent after fork(), the child process is leaked. We could plug the leak by inserting a new error handling section for killing the child process and reaping it with waitpid(). However, it would raise some new questions (what signal to send, ensure the child not ignore that signal, hope that whatever process

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

If the user calls nbd_kill_subprocess, we shouldn't kill the process again when we close the handle (since the process has likely gone and we might be killing a different process). --- lib/handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/handle.c b/lib/handle.c index 2af25fe..5ad818e 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -315,6 +315,8 @@

For commands with long names and/or short descriptors, you can end up going over 72 characters in the first line of the man page (causing podwrapper to complain). Wrap these lines. --- generator/generator | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/generator b/generator/generator index 7d3f656..ad1cb6b 100755 --- a/generator/generator +++ b/generator/generator

Hi, I' trying to read datas sent by my KVM host within the Guest. Host send these datas trough a channel UNIX type , by using AF_UNIX socket stuff. If i try to retrive the datas by using such type of thing in the Guest : #define NAME "/dev/virtio-ports/agent" sock = socket(AF_UNIX, SOCK_STREAM, 0); 12 if (sock < 0) { 13 perror("opening stream socket");

On Jan 12, 2014, at 11:07 AM, Ariel Wainer wrote: > On 11/01/14 15:27, Charles Lepple wrote: >> On Jan 10, 2014, at 4:46 PM, Ariel Wainer wrote: >> >>> On 10/01/14 01:53, Charles Lepple wrote: >>>> I am curious about why the Interrupt Out packet is sent by the Windows software if it isn't to turn off the UPS. Is it possible to do some more testing with

All, Running dovecot 2.3.10 on a CentOS 7.x and logging via syslog seems to stop when i restart rsyslog process. Reload doesnt get it working again only a dovecot restart. Tested this with dovecot 2.2.36 and this did not exhibit the same behaviour. systemctl restart dovecot rsyslog ----- this gets a working state systemctl restart rsyslog ------------- this restarts syslog other processes

This is a major rewrite compared to my v1 series, where I've tried a lot harder to ensure that we still accommodate building on Haiku (although I have not actually yet fired up a Haiku VM to try it for myself). I also managed to make the sh plugin fully parallel, on capable platforms. See also my question on patch 10 on whether I've picked the best naming convention. Eric Blake (17):