similar to: [PATCH] fish: fix the Ctrl-\ causes guestfish to abort bug(RHBZ#596761)

As the document said, the default value of "pgroup" should be false. Signed-off-by: Qixiang Wan <qwan at redhat.com> --- fish/fish.c | 2 +- src/guestfs.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/fish/fish.c b/fish/fish.c index 575fe99..fbacbb9 100644 --- a/fish/fish.c +++ b/fish/fish.c @@ -406,7 +406,7 @@ main (int argc, char *argv[])

The error message generated by perror() is not particularly useful to the user. Many other command line programs that can keep history around cope silently if they can't create or write to their history file. --- fish/fish.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/fish/fish.c b/fish/fish.c index b782b7c..bf976ea 100644 --- a/fish/fish.c +++ b/fish/fish.c @@

When running R from the terminal on Linux (Ubuntu 16.04), it core dumps whenever / wherever I press Ctrl-4 or Ctrl-\. You get thrown back to the terminal with "Quit (core dump)" being the only message. Grepping the R source code, it doesn't look like that message is generated by R itself. Over on Twitter, it has been confirmed to also happen on macOS. $ R -d valgrind --vanilla

Nothing new in the virt-tail command itself, but the second commit includes a simple test. Rich.

This adds a new tool which does a follow operation (ie. tail -f) on one or more log/text files inside the guest. I've only done limited testing, but it works for me for tailing various long-running builds inside guests which I'm doing at the moment. There are no tests at present. Rich.

Hi, this patch series fixes few more issues discovered by Coverity. Thanks, Pino Toscano (6): tail: check the return value pf guestfs_set_pgroup daemon: btrfs: check end_stringsbuf return values everywhere java: use cleanup handlers for structs (lists) as return values lib: qemu: improve handling of FILE* p2v: check more return values p2v: fix possible close(-1) issue cat/tail.c

This follows (tails) a log file within a guest, rather like the regular 'tail -f' command. For example: virt-tail -d guest /var/log/messages --- .gitignore | 3 + bash/Makefile.am | 4 +- bash/virt-alignment-scan | 6 + cat/Makefile.am | 47 ++++- cat/tail.c | 498 +++++++++++++++++++++++++++++++++++++++++++++++ cat/test-docs.sh

This follows (tails) a log file within a guest, rather like the regular 'tail -f' command. For example: virt-tail -d guest /var/log/messages --- .gitignore | 3 + bash/Makefile.am | 4 +- bash/virt-alignment-scan | 6 + cat/Makefile.am | 47 ++++- cat/tail.c | 502 +++++++++++++++++++++++++++++++++++++++++++++++ cat/test-docs.sh

Since v2: - Fix the things that Pino mentioned, except the recursion. - Implement Windows support. For Windows support to be sane, I had to inline the add_and_mount code. Rich.

Output is configurable, it's the same format as virt-log has, since both uses same code. First patch moves get_journal_field around and renames it to journal_view and the next one reimplements it a bit and brings it to guestfish. Maros Zatko (2): cat: move get_journal_field to fish/journal.c fish: add journal-view command (RHBZ#988100) .gnulib | 2 +-

On Monday, 3 October 2016 13:27:13 CEST Richard W.M. Jones wrote: > This follows (tails) a log file within a guest, rather like > the regular 'tail -f' command. For example: > > virt-tail -d guest /var/log/messages > --- > .gitignore | 3 + > bash/Makefile.am | 4 +- > bash/virt-alignment-scan | 6 + > cat/Makefile.am |

On Thu, 29 Dec 2022, Philippe Cerfon wrote: > Hey. > > On Thu, Dec 29, 2022 at 1:28 AM Damien Miller <djm at mindrot.org> wrote: > > It's because the monitor process doesn't explicitly handle SIGQUIT. > > Are you going to merge the patch of yours? Does it solve your problem? -d

Hey. I've noticed the following behavior and wondered whether it's possibly a bug or why it behaves like this: When having a SSH connection, than it seems there may be two sshd processes for that, one running as root the other as the user. As far as I know this is because of privilege separation, like e.g.: ??sshd(2931)???sshd(10174)???bash(10180) ?

Thanks for these explanations - it all makes sense, that is, the default behavior for a process that does not capture SIGQUIT is to quit and perform a core dump (https://en.wikipedia.org/wiki/Unix_signal#SIGQUIT). Then the remaining question, as Luke says, is: should R handle this signal? For instance, in interactive mode, SIGQUIT could maybe bring up: Possible actions: 1: abort (with core

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From d723a7c618cf764638e6da07e3b3abd72de30cb4 Mon Sep 17

In 1.11.1 / git, I have made some changes to the way that you run guestfish, guestmount and the virt tools from the build directory without installing. Firstly you can't just run ./fish/guestfish or ./fuse/guestmount any more and have those programs magically set LIBGUESTFS_PATH. The automagic code was always error-prone and I have removed it. Secondly, all of the run-*-local scripts have

We''re using unicornctl restart with the default before/after hook behavior, which is to reap old Unicorn workers via SIGQUIT after the new one has finished booting. Unfortunately, while the new workers are forking and begin processing requests, we''re still seeing significant spikes in our haproxy request queue. It seems as if after we restart, the unwarmed workers get swamped by

So do a number of other interactive programs when working in a terminal (e.g. python) since it looks like your terminal is configured for those two actions to send the SIGQUIT signal. Whether R should ignore that signal, under some circumstances at least, is another question. Best, luke On Fri, 10 Feb 2017, Henrik Bengtsson wrote: > When running R from the terminal on Linux (Ubuntu 16.04),

On command: #kill -9 `cat /var/run/sshd.pid` sshd leave pid file ! sshd.c code: =============== .... /* * Arrange to restart on SIGHUP. The handler needs * listen_sock. */ signal(SIGHUP, sighup_handler); signal(SIGTERM, sigterm_handler); signal(SIGQUIT, sigterm_handler); .... =============== Missing line is : signal(SIGKILL, sigterm_handler);

Hello, I''m using unicorn since a while, but now I try to run it the first time inside a FreeBSD jail. The initial start of unicorn works fine and it serves all the requests. But if I want to restart it using the USR2 signal, it (more or less) slowly starts using more and more CPU cycles. There is no error message in the logs and it quite hard to reproduce that error. In 1 of 20 tries,