similar to: [PATCH] Add waitpid along guestfs_close path (RHBZ#518747)

https://bugzilla.redhat.com/show_bug.cgi?id=769680

As Eric Blake noted in: https://www.redhat.com/archives/libguestfs/2016-April/msg00154.html libguestfs doesn't correctly handle the case where waitpid receives a SIGCHLD signal and the main program has registered a non-restartable signal handler. In this case waitpid would return -EINTR and we would print an error, but actually we should retry this case. This adds two new internal functions,

Hi! The handling of the "status" information in bsd-waitpid.c and bsd-nextstep.c seems to be bit odd. Patch attached. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz

On Thu, Nov 19, 2015 at 05:38:25PM +0100, Pino Toscano wrote: > When running commands in the mounted guest (using the "command" API, and > APIs based on it), provide the /dev/null from the appliance as open fd > for stdin. Commands usually assume stdin is open if they didn't close > it explicitly, so this should avoid crashes or misbehavings due to that. This does not

This package in Fedora enables optional support for Windows 10 "CompactOS" (file-level compression), read-only, which is sufficient for inspecting Windows guests and doing certain types of modifications to them. Virt-v2v appears to work, but it may be that anything that involves modifying a compressed file might not work. I couldn't find the equivalent package in Debian or SUSE.

On Tue, Dec 01, 2015 at 04:16:57PM +0100, Pino Toscano wrote: > On Tuesday 01 December 2015 15:59:56 Mateusz Guzik wrote: > > I would argue that /dev has to be at least partially populated for anything > > that gets executed in the chroot. At the very least special nodes like null, > > zero and {u,}random are needed. > > We do not assume anything about guests, which

Thanks: Eric Blake. --- src/Makefile.am | 1 + src/command.c | 7 ++---- src/guestfs-internal.h | 4 +++ src/launch-direct.c | 11 +++------ src/launch-uml.c | 11 +++------ src/umask.c | 10 ++------ src/wait.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 84 insertions(+), 27 deletions(-) create mode 100644

Forward from Laurent Julliiard. Any suggestions anyone? Dan >From: Laurent Julliard <Laurent.Julliard@xrce.xerox.com> >Reply-To: laurent@moldus.org >To: djberg96@hotmail.com >Subject: problem with win32 waitpid >Date: Thu, 18 Nov 2004 08:49:51 +0100 > >Dan, > >I am one of the developer of the FreeRIDE project (the Ruby

On Tuesday 01 December 2015 15:59:56 Mateusz Guzik wrote: > On Thu, Nov 19, 2015 at 05:38:25PM +0100, Pino Toscano wrote: > > When running commands in the mounted guest (using the "command" API, and > > APIs based on it), provide the /dev/null from the appliance as open fd > > for stdin. Commands usually assume stdin is open if they didn't close > > it

Hi, It looks like the current wait() method is actually a mix of wait and waitpid. Should we break this down into wait and waitpid for win32, just to keep the API consistent with the Unix version? Mind you, I''m not sure what flags, if any, would be valid for Win32 with regards to waitpid. Also, is wait2 a possibility? Regards, Dan

run_command uses Unix.create_process which forks a child process, and executes execve: the latter fails when the executable does not exist, triggering the exit which, in older OCaml versions [1], also runs the at_exit handlers. Since there is not much that can be done to avoid this on the OCaml side, to keep run_command working also in older OCaml version then manually search for the existance of

When running commands in the mounted guest (using the "command" API, and APIs based on it), provide the /dev/null from the appliance as open fd for stdin. Commands usually assume stdin is open if they didn't close it explicitly, so this should avoid crashes or misbehavings due to that. --- daemon/command.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)

https://bugzilla.redhat.com/show_bug.cgi?id=836710 https://bugzilla.redhat.com/show_bug.cgi?id=836913 There are at least two related bugs going on: (1) Linux sync(2) system call doesn't send a write barrier to the disk, so in effect it doesn't force the hard disk to flush its cache. libguestfs used sync(2) to force changes to disk. We didn't expect that qemu was caching anything

Hi I am writing a python test suite that uses oz (https://github.com/clalancette/oz) which uses libquestfs. I am simulating a small cloud and have some apps that need to talk to the guests. All works really well until I needed to start another process. So I start a process then "oz" starts up a VM (it uses libquestfs) then when "oz" cleans up it calls

Can I get people from other platforms to test the waitpid.patch to see if it solves hang-on-exit on their platform? I can confirm Solaris at this moment (but I've not done heavy testing at this moment) that is works like a charm (Solaris 7). It handles 'sleep 90&' vs 'nohup sleep 90&' correctly (killed, vs left). thanks. - Ben ---------- Forwarded message

On Wed, Jul 01, 2015 at 09:56:18AM -0600, Chris Murphy wrote: > On Wed, Jul 1, 2015 at 12:52 AM, Michael Wright > <michael_j.w09 at hotmail.com> wrote: > > Hi all I have downloaded centos and burn the iso file every time I install centos it deletes my windows 7 what am I doing wrong mike > > This lacks sufficient detail to answer your question, I can only > speculate

Added: - cdrtools: added as alternative to cdrkit - multipath-tools: contains kpartx (in AUR) Removed: - ntfsprogs: the package is no longer available, it has been completely replaced by ntfs-3g (already in packagelist.in) - zfs-fuse: no longer in AUR Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- appliance/packagelist.in | 4 ++-- 1 file changed, 2 insertions(+), 2

Let''s try that again, without Hotmail''s crappy formatting. Dan, I am one of the developer of the FreeRIDE project (the Ruby IDE) and I''m in charge of the FreeRIDE debugger with which we have had a number of problems on Windows now mostly due to the clunky implementation of IO/Process/Signal stuff on Win32. I recently came across your Win32 utils package and

I thought it would be easy to rewrite virt-make-fs in C. Two days later ... The Perl program uses a lot of external commands, which makes it pretty tedious to implement in C. Rich.

To Whom It May Concern: Below is a patch, that I have used to eliminate the unexplained errors in the rsync program. I was able to trace the problem to the order in which the sigchld_handler and wait_process routines were executed. If sigchld_handler executes first it retrieves the status that wait_process needs to indicate proper rsync termination. The code below allows the sigchld_handler to