search for: core_pattern

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 unchanged.

[PATCH 1/3] Add a core_pattern debug command The first patch is just a rework of Rich's earlier core dump patch. It turns it into a debug subcommand so it can be called at any time. This also has the advantage of explicitly labelling an extremely untidy API as debug. [PATCH 2/3] Call sync after guestfsd exits The second pat...

...ntion to Segmentation > error. > > Where should core file be created when Asterisk is run as a daemon by > asterisk user and group ? > Is there a setting I can use to specify the directory used (so that we can > make sure appropriate ownership is set) ? > "$ sysctl kernel.core_pattern" will show you where core files are written. For Asterisk to produce the core file, it has to be started with the '-g' option so make sure your asterisk.service file is adding the option. > > Cheers > > > 2016-09-05 13:36 GMT+02:00 Olivier <oza.4h07 at gmail.com&gt...

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

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?

...le be created when Asterisk is run as a daemon by > > > asterisk user and group ? > > > Is there a setting I can use to specify the directory used (so that we > can > > > make sure appropriate ownership is set) ? > > > > > > > "$ sysctl kernel.core_pattern" will show you where core files are > written. > > For Asterisk to produce the core file, it has to be started with the '-g' > > option so make sure your asterisk.service file is adding the option. > My asterisk.service is : # cat /run/systemd/generator.late/asteris...

...t;> > > asterisk user and group ? >>> > > Is there a setting I can use to specify the directory used (so that >>> we can >>> > > make sure appropriate ownership is set) ? >>> > > >>> > >>> > "$ sysctl kernel.core_pattern" will show you where core files are >>> written. >>> > For Asterisk to produce the core file, it has to be started with the >>> '-g' >>> > option so make sure your asterisk.service file is adding the option. >>> >> >> My as...

...ess died unexpectedly Haven't seen this with previous versions. But somehow I fail to get the core dump. I do 'ulimit -c unlimited' before starting dovecot, I set * soft core 8192 * hard core 8192 in limits.conf, /proc/sys/kernel/core_pattern is set to /tmp/core. Regards, Jiri Novosad My dovecont -n: # 1.1.13: /packages/run.64/dovecot-1.1.13//etc/dovecot.conf # OS: Linux 2.6.18-92.1.22.el5 x86_64 Red Hat Enterprise Linux Server release 5.3 (Tikanga) ext3 base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/log info_log_path: /var/l...

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: free(): invalid pointer: 0x08cbd600 *** Jun 22 00:05:53 postamt dovecot: child 2887...

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

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 ulimit -c unlimited -> -> OK > > and you should get a core.* file in the current directory when qemu-img segfaults. Attach that file to gdb to get a stac...

..._start+0x2e) [0x56316272ae8e] > Jul 28 09:18:51 midway3-dm1.rcc.local winbindd[1056745]: [2023/07/28 09:18:51.432424,? 0] ../../source3/lib/dumpcore.c:318(dump_core) > Jul 28 09:18:51 midway3-dm1.rcc.local winbindd[1056745]:?? coredump is handled by helper binary specified at /proc/sys/kernel/core_pattern > Jul 28 09:18:51 midway3-dm1.rcc.local winbindd[1056745]: It is a Saturday here and I've not digested the entire thread, but this is the end of a backtrace and if Samba is crashing it is no supprise if things are not working. Please supply that full backtrace and debug that first. Andrew...

...24 is lower than what Dovecot can use under full load (more than 1712). Either grow the limit or change login_max_processes_count and max_mail_processes settings But in my /var/service/dovecot/run script I use: #!/bin/sh mkdir /var/core chmod 1777 /var/core echo /var/core/%p > /proc/sys/kernel/core_pattern ulimit -n unlimited ulimit -c unlimited /usr/local/sbin/dovecot -F So how can I raise the filedescriptor limit above 1024 (linux-2.6.24.2, Debian)? -- Ralf Hildebrandt (Ralf.Hildebrandt at charite.de) snickebo at charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30...

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

...-- daemon/sync.c | 2 +- daemon/uuids.c | 4 ++-- daemon/xfs.c | 16 ++++++++-------- 12 files changed, 40 insertions(+), 40 deletions(-) diff --git a/daemon/debug.c b/daemon/debug.c index 92f5aa6..a210db1 100644 --- a/daemon/debug.c +++ b/daemon/debug.c @@ -588,7 +588,7 @@ debug_core_pattern (const char *subcmd, size_t argc, char *const *const argv) } const char *pattern = argv[0]; - const size_t pattern_len = strlen(pattern); + const size_t pattern_len = strlen (pattern); #define CORE_PATTERN "/proc/sys/kernel/core_pattern" int fd = open (CORE_PATTERN, O_WRON...

Sorry I forgot the -v options. The source is a local disk image. Alain VONDRA Chargé d'exploitation des Systèmes d'Information Direction Administrative et Financière +33 1 44 39 77 76 UNICEF France 3 rue Duguay Trouin 75006 PARIS www.unicef.fr -----Message d'origine----- De : Richard W.M. Jones [mailto:rjones@redhat.com] Envoyé : lundi 13 octobre 2014 23:09 À : VONDRA Alain Cc

Hi, We've observed frequent auth failure recently from the SquirrelMail frontend. The imap server is the dovecot-1.0.7-2 from Centos 5.2. The auth backend is a pgsql database on another server. The only way to make it work is to restart the dovecot, though sometimes it'll recover automatically, but you don't know when. At first we thought there might be a network problem, but we

...OR message whenever it detects, >> at startup preferably, that it has not required permissions to write a >> coredump file ? >> > > No because it's the system that determines where a coredump goes and > actually writes it, not asterisk. > It's the sysctl kernel.core_pattern setting. > > >> >> 3. Among above directories, which one is choosen to save coredump files ? >> Is it something that can/should be configured in /etc/asterisk (I've seen >> related options in some debian /etc/default/asterisk files but I would be >> curious...

Where would I find the core file? I'm not finding anything obvious. The replicator path is /usr/local/libexec/dovecot/replicator Daniel On 3/22/2017 12:52 AM, Aki Tuomi wrote: > Can you provide us gdb bt full dump? > > gdb /usr/libexec/dovecot/replicator /path/to/core > > on some systems, it's /usr/lib/dovecot/replicator > > Aki > > On 21.03.2017 23:48,

Hello Matthew, I have compiled Asterisk 13.2 with the following compiler Flags enabled: DON'T_OPTIMIZE DEBUG THREADS BETTER_BACKTRACES My asterisk is running with the asterisk_script: root 24048 39.4 2.4 128564 50640 pts/1 Sl 00:02 2:21 /usr/sbin/asterisk -f -vvvg -c core show locks ======================================================================= === 13.2.0 ===