similar to: [Bug 435] New: internal entropy gatherer

http://bugzilla.mindrot.org/show_bug.cgi?id=435 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|internal entropy gatherer |internal entropy gatherer ------- Additional Comments From dtucker at zip.com.au 2002-11-15 00:21 ------- Which platform did you

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

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

On Wed, Dec 02, 2015 at 02:00:57PM +0100, Pino Toscano wrote: > - add a flag to request chroot for the process, which is done only as > very last (before chdir) operation before exec'ing the process in the > child: this avoids using CHROOT_IN & CHROOT_OUT around command* > invocations, and reduces the code spent in chroot mode > - add failure checks for dup2 and open

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

- add a flag to request chroot for the process, which is done only as very last (before chdir) operation before exec'ing the process in the child: this avoids using CHROOT_IN & CHROOT_OUT around command* invocations, and reduces the code spent in chroot mode - add failure checks for dup2 and open done in child, not proceeding to executing the process if they fail - open /dev/null

Improve readability of commandrvf() by replacing bare int values for file descriptors with their symbolic names STD{IN,OUT,ERR}_FILENO. Also add PIPE_READ and PIPE_WRITE for referencing relevant ends of a pipe. --- daemon/guestfsd.c | 79 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 42 insertions(+), 37 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c

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

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

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

Allows more sharing between the daemon and the inspection program. --- daemon/Makefile.am | 2 + daemon/cleanups.c | 80 ++++++++++ daemon/cleanups.h | 47 ++++++ daemon/command.c | 436 +++++++++++++++++++++++++++++++++++++++++++++++++++++ daemon/command.h | 41 +++++ daemon/daemon.h | 47 +----- daemon/guestfsd.c | 392 ----------------------------------------------- po/POTFILES

https://www.redhat.com/archives/libguestfs/2019-August/thread.html#00347 Thanks: Eric Blake and Daniel P. Berrangé --- common/utils/utils.h | 1 + server/connections.c | 4 ++-- server/crypto.c | 5 +++-- server/main.c | 23 +++++++++++++++++++++++ common/utils/utils.c | 29 +++++++++++++++++++++++++++++ 5 files changed, 58 insertions(+), 4 deletions(-) diff --git

Hello all, My scripts, which read stdout from ssh, weren't seeing EOF from the remote session.? It was being sent, but lost.? I tracked it down to the following code, in ssh.c, at ssh_session2_open: ??????? if (stdin_null_flag) { ??????????????? in = open(_PATH_DEVNULL, O_RDONLY); ??????? } else { ??????????????? in = dup(STDIN_FILENO); ??????? } ??????? out = dup(STDOUT_FILENO);

Please review the function below, forkoff(), meant to be used in clientloop.c instead of daemon() and the code in process_escapes(). The intention is to make ~D ( like ~& but also detach) possible and to make it possible for ssh -f (or ssh -f -f - see other thread on this) to detach, not just forkoff(). I also intend to use the same detach technique in a feature patch for the hang-on-exit

Hi I'm trying to wrap ssh in an application using glib. For now, I'm launching the ssh client in master mode and want it to detach, keeping the control socket around. I figured I could do that using the -f flag and the usual Control* options to force ssh to daemonize (ideally without executing any command), but it turns out that glib doesn't recognize the daemonized process as

The following patch allows OpenSSH 2.2.0-p1 to be started (and managed) from /etc/inittab (by "init") on systems which support that. This is useful when you *really* want SSHD to always run since it will be automatically restarted by "init" if it dies (and if "init" dies the the systems dies :-). I use a line (in /etc/inittab) like this on Solaris systems:

Background ========== "ssh -f ..." causes ssh to fork into the background when userauth successfully completes. WHAT === With this patch "ssh -f -f ..." causes ssh to fork into the background when the first forwarded port/x11 display/agent is successfully opened. WHY === This feature makes launching remote X11 apps more reliable: when ssh exits it must have exited because

Markus, How's this patch? - a chan_wont_read()/chan_wont_write() API is added that is very much like chan_read_failed()/chan_write_failed(), but for the debug messages and chan_wont_*() don't ever call error() The 3.0.2p1 channel_pre_x11_open() uses chan_*_failed() but looks like it ought to use chan_wont_*() instead :) - forkoff() no longer fakes EOF for SSHv2 (still

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

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