similar to: [nbdkit PATCH] server: Enforce sane stdin/out/err

On 8/27/19 6:47 AM, Richard W.M. Jones wrote: > On Fri, Aug 02, 2019 at 02:26:15PM -0500, Eric Blake wrote: >> + /* Ensure that stdin/out/err of the current process were not empty >> + * before we started creating pipes (otherwise, the close and dup2 >> + * calls below become more complex to juggle fds around correctly). >> + */ >> + assert (in_fd[0] >

On Fri, Aug 02, 2019 at 02:26:15PM -0500, Eric Blake wrote: > + /* Ensure that stdin/out/err of the current process were not empty > + * before we started creating pipes (otherwise, the close and dup2 > + * calls below become more complex to juggle fds around correctly). > + */ > + assert (in_fd[0] > STDERR_FILENO && in_fd[1] > STDERR_FILENO && > +

Technically, as long as our thread model is SERIALIZE_ALL_REQUESTS, we don't have to be very careful about atomic CLOEXEC on any of the pipes we create for communication with the child. However, the next patch wants to promote sh plugin to parallel when possible, which requires the use of pipe2 to avoid fd leaks. Also, add an assert to ensure that we avoid dup2(n, n) (which would fail to

On 8/27/19 7:55 AM, Eric Blake wrote: > On 8/27/19 6:47 AM, Richard W.M. Jones wrote: >> On Fri, Aug 02, 2019 at 02:26:15PM -0500, Eric Blake wrote: >>> + /* Ensure that stdin/out/err of the current process were not empty >>> + * before we started creating pipes (otherwise, the close and dup2 >>> + * calls below become more complex to juggle fds around

As shown in the previous patch, plugins may choose to use stdin or stdout during .config. But from .get_ready onwards, well-written plugins shouldn't be needing any further use of stdin/out. We already swapped stdin/out to /dev/null while daemonizing, but did not do do during -f or --run, which leads to some surprising inconsistency when trying to debug a plugin that works in the foreground

While nbdkit itself must run with SIGPIPE ignored, many applications expect to inherit SIGPIPE in the default state. What's worse, POSIX states that a non-interactive shell script cannot use 'trap' to undo an inherited SIG_IGN on SIGPIPE. I have seen several bug reports over the years of something that works for a developer but fails under a CI environment, where the root cause was

As shown in the previous patch, plugins may choose to use stdin or stdout during .config. But from .get_ready onwards, well-written plugins shouldn't be needing any further use of stdin/out. We already swapped stdin/out to /dev/null while daemonizing, but did not do do during -f or --run, which leads to some surprising inconsistency when trying to debug a plugin that works in the foreground

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):

Get also the fd for the tar subprocess, and drain and print its content if the tar invocation fails. --- src/copy-in-out.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/src/copy-in-out.c b/src/copy-in-out.c index dc9e7b7..0dd8cd3 100644 --- a/src/copy-in-out.c +++ b/src/copy-in-out.c @@ -34,17 +34,19 @@ #include

$ ./nbdkit ssh host=localhost /nosuchfile password=-0 --run 'qemu-img info $nbd' abc fcntl: Bad file descriptor The reason for this is that we close the file descriptor after reading the password. Closing stdin causes bad stuff to happen. --- docs/nbdkit-plugin.pod | 5 +++++ server/public.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git

Trying to read a password or inline script from stdin when the -s option was used to connect to our client over stdin is not going to work. It would be nice to fail such usage as soon as possible, by giving plugins a means to decide if it is safe to use stdio during .config. Update nbdkit_read_password and the sh plugin to take advantage of the new entry point. Also, treat 'nbdkit -s

On Wed, Feb 15, 2023 at 03:11:36PM +0100, Laszlo Ersek wrote: > Add an assert() variant that we may call between fork() and exec*(). > > Signed-off-by: Laszlo Ersek <lersek at redhat.com> > --- > > +++ b/lib/internal.h > + > +#ifdef NDEBUG > +#define NBD_INTERNAL_FORK_SAFE_ASSERT(expression) ((void)0) May be affected by outcome of side discussion on 01/29

Trying to read a password or inline script from stdin when the -s option was used to connect to our client over stdin is not going to work. It would be nice to fail such usage as soon as possible, by giving plugins a means to decide if it is safe to use stdio during .config. Update nbdkit_read_password and the sh plugin to take advantage of the new entry point. Signed-off-by: Eric Blake

On 2/15/23 21:57, Eric Blake wrote: > On Wed, Feb 15, 2023 at 03:11:36PM +0100, Laszlo Ersek wrote: >> Add an assert() variant that we may call between fork() and exec*(). >> >> Signed-off-by: Laszlo Ersek <lersek at redhat.com> >> --- >> > >> +++ b/lib/internal.h > >> + >> +#ifdef NDEBUG >> +#define

Hi, I fell on this using openssh on cygwin. Though it may be a cygwin related issue, I think it's may be a bug on the main openssh tree. Thus my posting here. I'm CC'ing to the public list for information. The part of code I'm refering to is : /* XXX might close listen socket */ (void)dup2(fd, STDIN_FILENO); (void)dup2(fd, STDOUT_FILENO);

coding style fixes. FIXME: check that compiled bin the same1!! --- usr/kinit/initrd.c | 3 ++- usr/kinit/kinit.c | 12 ++++-------- usr/kinit/kinit.h | 20 ++++++++++---------- usr/kinit/name_to_dev.c | 6 +++--- usr/kinit/nfsroot.c | 5 ++--- 5 files changed, 21 insertions(+), 25 deletions(-) diff --git a/usr/kinit/initrd.c b/usr/kinit/initrd.c index

On 2/20/23 19:21, Laszlo Ersek wrote: > On 2/15/23 21:57, Eric Blake wrote: >> On Wed, Feb 15, 2023 at 03:11:36PM +0100, Laszlo Ersek wrote: >>> + >>> + xwrite (STDERR_FILENO, file, strlen (file)); >>> + xwrite (STDERR_FILENO, ":", 1); >> >> Presumably, if our first best-effort xwrite() fails to produce full >> output, all later

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

At least it appears that way on my FreeBSD 8.1 system. This is probably unnoticeable in regular use but I happen to use CFengine(v2) for system configuration & monitoring. If it notices dovecot not running it tries to start it and hangs. I believe cfengine (cfagent) has created a pipe to monitor the start commmand's stderr and is waiting for this pipe to close. This never happens