15 thoughts on - Feature Request: What About “core Stop Panic” ?

• How about just running “pkill -SEGV -f /usr/sbin/asterisk” from the shell?
  Works for me.

• 2016-09-02 20:40 GMT+02:00 George Joseph :

  It seems to comply to what I’m after. Thank you very for sharing this here.

• 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, I can read on Asterisk console:
  *CLI> Segmentation error (core dumped)
  (*) I translated into english the exact output I got.

  I see a /tmp/core file exists.

  My asterisk.conf includes:
  full = verbose,notice,warning,error,debug

  After Asterisk’s stop, my /var/log:asterisk/full doesn’t include any mention to Segmentation error. I cannot find anything in dmesg, /var/log/messages or /var/log/kern.log as I did when a real segmentation fault occurred on production system.

  I would expect Asterisk to log something. Is this expected behaviour ?

  2. When I issue a “cd /tmp; systemctl start asterisk” command, and then issue a “pkill -SEGV asterisk” command, I can read on Asterisk console:
  Disconnected from Asterisk server Asterisk cleanly ending (0). Executing last minute cleanups

  I cannot find any core file anyware.

  File /var/log:asterisk/full doesn’t include any mention 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) ?

  Cheers

  2016-09-05 13:36 GMT+02:00 Olivier :

• Yes. Asterisk can’t really log anything when it ends abruptly because of critical signals like SEGV and since it was user initiated, rather than an actual SEGV, there won’t be a message in the kernel log buffer.

  “$ 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.

• Specifically, if the first character of core_pattern is ‘!’, the rest should be an executable, to which the core file is handled. IIRC CentOS7
  had something of that type installed by default. On Debian Stable you have the package corekeeper (or maybe also systemd-coredump from backports). I haven’t tried any of those.

• I think that should be a ‘pipe,’ not an exclamation mark to hand off the core to an executable.

• 2016-09-06 14:37 GMT+02:00 George Joseph :

  My system shows:
  # ps aux | grep asteri asterisk 429 7.3 2.4 59468 25088 ? Ssl 18:47 0:03
  /usr/sbin/asterisk -U asterisk -G asterisk -g
  …
  # sysctl kernel.core_pattern kernel.core_pattern = core

  Option -g is present.

  So either, the “pkill -SEGV asterisk” command doesn’t trigger any coredump
  “Asterisk cleanly ending (0)”, either the core dump is not produced (find / -name “core.*” doesn’t find anything) for some reason.

• 2016-09-06 17:48 GMT+02:00 Tzafrir Cohen :

  My asterisk.service is :

  # cat /run/systemd/generator.late/asterisk.service
  # Automatically generated by systemd-sysv-generator

  [Unit]
  SourcePath=/etc/init.d/asterisk Description=LSB: Asterisk PBX
  Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target After=network-online.target systemd-journald-dev-log.socket nss-lookup.target local-fs.target remote-fs.target dahdi.service misdn.service lcr.service wanrouter.service mysql.service postgresql.service Wants=network-online.target Conflicts=shutdown.target

  [Service]
  Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=2
  ExecStart=/etc/init.d/asterisk start ExecStop=/etc/init.d/asterisk stop ExecReload=/etc/init.d/asterisk reload

  My /etc/init.d/asterisk file is sourcing my /etc/default/asterisk which includes an (uncommented) line COREDUMP=yes. I also have
  # grep core /etc/asterisk/asterisk.conf dumpcore = yes

  make menuselect shows:
  [*] DONT_OPTIMIZE
  [*] COMPILE_DOUBLE
  [ ] DEBUG_THREADS
  [*] LOADABLE_MODULES
  [ ] DEBUG_FD_LEAKS
  [*] BETTER_BACKTRACES
  [ ] LOTS_OF_SPANS
  [ ] MALLOC_DEBUG
  [ ] DEBUG_CHAOS
  [*] BUILD_NATIVE
  — Extended –

• Since “core” is a relative file name, the file will be in whatever the working directory is for the process. You may have to hunt it down. For better debugging, you might want to set core_pattern to something like
  ” /tmp/core-%e-%t”. That way all core files will have a name like
  “/tmp/core-asterisk-1473164587.7705”. “man core” should give you more info on constructing the file name.

• If -g is specified a core file should always be produced. See my earlier reply. I think one is being produced, it’s just not where you think it should be. 🙂

• 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 dumped)

  and a /core file is created

  I also tried with asterisk run asterisk user and group and looked for any newly created (find / -cmin -2) : nothing looking like a core file, though I might overlooked it.

  So, it really look like a configuration issue: “how to specify, with asterisk and systemd among others, where core files are dumped ?”.

  I’ll read again this thread advices and report back here.

  2016-09-07 21:44 GMT+02:00 George Joseph :

• Adding an /etc/sysctl.d/foobar.conf file with the bellow content allowed me to at last produce core dump files (in /var/tmp directory), even if asterisk is run by asterisk user (and by root). I choosed this /var/tmp directory to make sure core dumps are not erased after a reboot and because this directory is “world-writable”. To trigger core dumping, previously recommended “pkill -SEGV asterisk” was used.

  /etc/sysctl.d/foobar.conf content is simply:
  kernel.core_pattern=/var/tmp/core.%e.%t

  Maybe taming systemd to consider /var/lib/asterisk as a current directory when running asterisk daemon would be a better solution ?

  Maybe Asterisk or more generally long running daemons, should warn when they are run with “-g option” and from a current directory where it can’t write any file (or any file matching core pattern) ?
  Maybe this is already done but I overlooked it or looked in the wrong place
  ?

  Anyway, thank you very much to all.

  2016-09-08 16:22 GMT+02:00 Olivier :

• Why not just use the systemd journal and coredumpctl for core files management? systemd solves that quite well.

  Jacek

• 2016-09-09 13:24 GMT+02:00 Jacek Konieczny :

  Do you have any pointer showing how systemd journal or coredumpctl can help
  ?
  How can any of those help to specify the where core files are dumped ?

• But looking at the process of asterisk may help:

  ls -l /proc/$PID_OF_ASTERISK/cwd