similar to: Generate coredumps of the guestfs appliance

This is a repost of a previously posted set. It's been updated following review comments. [PATCH 1/4] Add a core_pattern debug command Added missing return statements. [PATCH 2/4] Call sync after guestfsd exits Remove redundant sleep 1; sync [PATCH 3/4] Shut down the appliance cleanly [PATCH 4/4] Ignore launch() error in virt-rescue These were previously 2 patches. They are otherwise

These two patches are probably not completely independent, but separating them is a lot of work. With *both* patches applied, all the tests and extra-tests pass. That's no guarantee however that there isn't a mistake, so I don't think this patch is a candidate for the 1.16 branch, until it's had a lot more testing in development. Rich.

Hi, this patch series improves the way /usr filesystems are handled: tag them appropriately, so later on we can find them and merge results they contain directly back for the root filesystem. The series includes also a new private debug API, and its usage to fix the resolution of /dev/mapper/.. devices found in fstab; without it, LVM /usr filesystems are not recognized as belonging to their

more daemon codes covered Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com> --- daemon/debug.c | 2 +- daemon/devsparts.c | 2 +- daemon/guestfsd.c | 6 +++--- daemon/labels.c | 4 ++-- daemon/ldm.c | 16 ++++++++-------- daemon/md.c | 10 +++++----- daemon/mkfs.c | 2 +- daemon/parted.c | 8 ++++---- daemon/statvfs.c | 8 ++++---- daemon/sync.c

For convenience you can pull it from the 'build' branch in: git://heisenbug.com/matthew/libguestfs.git Matt

Here are a few warning-removal changes for daemon/: >From eea38a1937ccd396603ed899d829d2982755ea4a Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Thu, 6 Aug 2009 15:25:03 +0200 Subject: [PATCH 1/4] define ATTRIBUTE_UNUSED * daemon/daemon.h (__attribute__, ATTRIBUTE_UNUSED): Define. --- daemon/daemon.h | 10 ++++++++++ 1 files changed, 10 insertions(+), 0

With this, "make syntax-check" runs a few more tests, all passing. >From febff9d2a35c4f40abbaf8943146476bdeac671e Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Tue, 4 Aug 2009 13:49:19 +0200 Subject: [PATCH 1/8] build: remove more files added by ./autogen.sh * po/LINGUAS: Remove file. * po/Makefile.in.in: Likewise. * po/Makevars: Likewise. *

On Tue, Sep 6, 2016 at 1:55 AM, Olivier <oza.4h07 at gmail.com> wrote: > Hello, > > After testing "pkill -SEGV -f /usr/sbin/asterisk" on Debian Jessie > platform, I've got several questions : > > > 1. When I issue a "cd /tmp; asterisk -cvvvvvvvvvvvg -U asterisk -G > asterisk" command, and then issue a "pkill -SEGV asterisk" command,

Hi Jiffin, On Fri, Jan 19, 2018 at 09:19:45AM +0530, Jiffin Tony Thottan wrote: > It will be very easy to debug if u have core file with u. It looks like > crash is coming from gfapi stack. > > If there is core file can u please share bt of the core file. I'm sorry, there are no core files. :( Is there something I could do to trigger the creation of core files? Or anything else

- Btrfs-progs v4.1 introduced new feature of changing uuid of btrfs partition. This patch add support of this. - Introduce set_uuid_random - uuids.c did a lot of deplicated work for changing uuid of fs. Use existing functions. v4: introduce get_random_uuid improve testcases squash internal API patches v3.1: fix typos v3: set errno if feature is not available. Chen Hanxiao (7):

blkid(1) (or actually, libblkid) seems to handle file system labels up to 127 characters. Considering that btrfs labels can be up to 255 characters, this means long labels are not read correctly (i.e. get truncated) by blkid. Get the file system type, and if btrfs is available invoke `btrfs filesystem` to get the label of btrfs file systems. --- daemon/blkid.c | 6 ++++++ daemon/btrfs.c | 24

What's /proc/sys/kernel/core_pattern set to for you? For me it is % cat /proc/sys/kernel/core_pattern core which will drop a core file in the working directory of the process. On 19/01/2018 12.56, Frank Wall wrote: > Is there something I could do to trigger the creation of core files?

2016-09-06 17:48 GMT+02:00 Tzafrir Cohen <tzafrir.cohen at xorcom.com>: > On Tue, Sep 06, 2016 at 06:37:52AM -0600, George Joseph wrote: > > On Tue, Sep 6, 2016 at 1:55 AM, Olivier <oza.4h07 at gmail.com> wrote: > > > > Where should core file be created when Asterisk is run as a daemon by > > > asterisk user and group ? > > > Is there a setting I

I think were getting closer: I did: - I edited /etc/default/asterisk to include : AST_USER="root" AST_GROUP="root" # systemctl daemon-reload # systemctl start asterisk # ps aux | grep asterisk root 3602 7.1 2.5 60332 26012 ? Ssl 16:00 0:03 /usr/sbin/asterisk -U root -G root -g # rasterisk # pkill -SEGV asterisk Then console showed: Segmentation error (core

Does any one know how to change astmanproxy to be able to a) compile without optimisations b) dump a core I've had it crash several times over the past couple of months, but there is no way to debug what's going on. I like the way a core is produced when (if!) * crashes, and would like to have the same thing on astmanproxy. Thanks Julian

Hi, I get these errors with dovecot 1.1.13 in my logs: dovecot: Mar 27 12:00:34 Error: auth-worker(default): *** glibc detected *** dovecot-auth: double free or corruption (!prev): 0x00002b30d5a7dd90 *** dovecot: Mar 27 12:00:34 Error: auth(default): worker-server(jan,147.251.48.141): Aborted: Worker process died unexpectedly dovecot: Mar 27 12:00:34 Error: child 21838 (auth-worker) killed with

- Btrfs-progs v4.1 introduced new feature of changing uuid of btrfs partition. This patch add support of this. - Introduce set_uuid_random - uuids.c did a lot of deplicated work for changing uuid of fs. Use existing functions. v5: use NOT_SUPPORTED macro improve testcases v4: introduce get_random_uuid improve testcases squash internal API patches v3.1: fix typos v3: set errno

I'm getting some cra shes with 1.1.1, but even with these start options: #!/bin/sh mkdir /var/core chmod 1777 /var/core echo /var/core/%p > /proc/sys/kernel/core_pattern ulimit -n 65535 ulimit -c unlimited /usr/local/sbin/dovecot -F I'm not getting any corefiles - why? It definitely used to work :) Jun 22 00:05:53 postamt dovecot: imap-login: *** glibc detected *** imap-login:

On Tue, Oct 14, 2014 at 02:43:31PM +0000, VONDRA Alain wrote: > Rich, > The conversion did'nt finish, and I don't have any core dump. > The qemu-img seems to hang, but doesn't crash... Please connect gdb to the hung process and get a stack trace to find out where it's hanging. 'strace -p ...' output might also be enlightening, if it is not hung but doing

On Tue, Oct 14, 2014 at 03:40:22PM +0000, VONDRA Alain wrote: > Rich, > I've followed your instructions to trace, but I am not very skilful with gdb, maybe I made a mistake : > > (1) As root do: > > echo core.%p > /proc/sys/kernel/core_pattern -> OK > > (2) Before running virt-v2v, do: > > ulimited -c unlimited -> I think it's