Thanks Lonnie
I guess I am probably more concerned about going from 13 back to 11 than the
security issues in 13.14.1.
Regards
Michael Knill
-----Original Message-----
From: Lonnie Abelbeck <li...@lonnie.abelbeck.com>
Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
Date: Friday, 29 September 2017 at 9:58 am
To: AstLinux List <astlinux-users@lists.sourceforge.net>
Subject: Re: [Astlinux-users] Asterisk Segfault in app_queue.so
Asterisk 13 is fine unless you get bitten by an obscure, hard to find, hard to
fix bug, as you have in app_queue.c .
Asterisk 13 code is still changing, Asterisk 11 code is not changing (except
for security fixes) ... There are pros and cons to each when building a stable
production system.
At this point in time it would seem Asterisk 11 or Asterisk 13.14.1 is required
for production app_queue usage. Arguably Asterisk 11.25.3 is more secure than
going back to Asterisk 13.14.1.
Lonnie
On Sep 28, 2017, at 6:14 PM, Michael Knill <michael.kn...@ipcsolutions.com.au>
wrote:
> Hi Michael
>
> Lonnie mentioned that too. Was it a bad move upgrading to Asterisk 13 do you
> think?
>
> Regards
> Michael Knill
>
> -----Original Message-----
> From: Michael Keuter <li...@mksolutions.info>
> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Date: Friday, 29 September 2017 at 9:04 am
> To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Subject: Re: [Astlinux-users] Asterisk Segfault in app_queue.so
>
>
>> Am 28.09.2017 um 02:28 schrieb Michael Knill
>> <michael.kn...@ipcsolutions.com.au>:
>>
>> Hi Michael
>>
>> All my other VM systems only have a single core however when Monit told me
>> that I was having resource issues, then I pushed it up to 2 cores.
>> The thing is however that Monit didn't complain until queueing was
>> configured but Asterisk did not crash until 2 cores were added.
>> Note that this could be coincidence as there was not a lot of time between
>> these events but we are going to try a faster single core to see if this
>> fixes the problem.
>>
>> Here is my queueing module. Its actually an overflowing queue group which is
>> how they wanted it to work. Not sure if this dialplan architecture is
>> conducive to bad stuff happening?
>>
>> [subDialCustom-Queuegroup]
>> ;ARG1 - Queue Group, ARG2 - CF and max queue time destination dial plan
>> exten => start,1,Gosub(subSetConn,start,1(${ARG1},Queue Group))
>> ;Set ext_cid for when a call is forwarded externally
>> same =>
>> n,Set(__ext_cid=${IF($[${DB_EXISTS(${ARG1}/ext_cid)}]?${DB_RESULT}:${ext_cid})})
>> same => n,GotoIf(${DB(${ARG1}/cfa)}?cfa)
>> same =>
>> n,Set(queue_options=${IF($[${DB_EXISTS(${ARG1}/queue_options)}]?${DB_RESULT}:)})
>> same =>
>> n,ExecIf(${DB(${ARG1}/natimer)}?set(queue_timeout=${DB(${ARG1}/natimer)}:set(queue_timeout=${default_natimerqg}))
>> ;Set and check announcement file
>> same =>
>> n,Set(announcefile=${IF($[${DB_EXISTS(${ARG1}/welcome_ann)}]?announce${DB_RESULT}:)})
>> same =>
>> n,Set(announcefile=${IF($[${DB_EXISTS(${DB_RESULT}/audiofile)}]?${DB_RESULT}:${announcefile})})
>> same => n,GotoIf($[${ISNULL(${announcefile})}]?bypass_filecheck)
>> same =>
>> n,ExecIf($["${STAT(e,${monitor_path}${announcefile}.wav)}"="0"]?Goto(no_welcome_file))
>> same => n(bypass_filecheck),Answer
>> same => n,ExecIf($[${ISNULL(${announcefile})}]?NoOp(Do
>> nothing):Playback(${monitor_path}${announcefile}))
>> same => n,Queue(${ARG1},,,,10)
>> same => n,MusicOnHold(default,1)
>> same => n,Queue(Qoverflow1,,,,10)
>> same => n,MusicOnHold(default,1)
>> same => n,Queue(Qoverflow2,,,,10)
>> same => n,MusicOnHold(default,1)
>> same => n,Queue(Qoverflow3,,,,300)
>> same => n,Hangup
>> same => n(cfa),Dial(Local/${DB(${ARG1}/cfa)}@${ARG2})
>> same => n,Hangup
>> same => n(no_welcome_file),Log(WARNING,Welcome announcement ${announcefile}
>> for Queue ${ARG1} does not exist)
>> same => n,Hangup
>>
>> Thanks
>>
>> Regards
>> Michael Knill
>
> Hi Michael,
>
> the dialplan looks OK to me.
> Have you tried (for testing purpose) to use Asterisk 11?
>
> I also never had this "low resources" warning.
> How many concurrent call does the VM handle?
>
>> -----Original Message-----
>> From: Michael Keuter <li...@mksolutions.info>
>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
>> Date: Wednesday, 27 September 2017 at 5:55 pm
>> To: AstLinux List <astlinux-users@lists.sourceforge.net>
>> Subject: Re: [Astlinux-users] Asterisk Segfault in app_queue.so
>>
>>
>>> Am 27.09.2017 um 03:47 schrieb Michael Knill
>>> <michael.kn...@ipcsolutions.com.au>:
>>>
>>> Actually I did have a thought. These problems could very well have started
>>> when an additional CPU was added to the VM!
>>>
>>> Regards
>>> Michael Knill
>>
>> What Hypervisor and how many CPUs/Cores are you using?
>>
>> I have a few VMs running under Proxmox with "1 Socket, 2 Cores" (as
>> described in our Wiki).
>> But unfortunately none of them uses Queues.
>>
>>> -----Original Message-----
>>> From: Michael Knill <michael.kn...@ipcsolutions.com.au>
>>> Date: Wednesday, 27 September 2017 at 10:56 am
>>> To: AstLinux List <astlinux-users@lists.sourceforge.net>
>>> Subject: Re: [Astlinux-users] Asterisk Segfault in app_queue.so
>>>
>>> Damn it just happened again. I would like to report it to Digium but I
>>> suspect that they will want a backtrace (
>>> Do you have any suggestions what else I can try?
>>>
>>> Regards
>>> Michael Knill
>>>
>>> -----Original Message-----
>>> From: Lonnie Abelbeck <li...@lonnie.abelbeck.com>
>>> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
>>> Date: Thursday, 21 September 2017 at 10:11 pm
>>> To: AstLinux List <astlinux-users@lists.sourceforge.net>
>>> Subject: Re: [Astlinux-users] Asterisk Segfault in app_queue.so
>>>
>>> Hi Michael,
>>>
>>> I took a look at the Asterisk source and the last "segfault" fix to
>>> apps/app_queue.c was back in 2016-04-18, which is included in Asterisk
>>> 11.23.0. (AstLinux 1.2.8)
>>>
>>> Asterisk Git Repo:
>>> http://git.asterisk.org/gitweb/?p=asterisk/asterisk.git;a=summary
>>>
>>> Scroll to bottom under "heads", you can compare different versions there,
>>> or browse the very latest under "master"
>>> --
>>> 7 weeks ago master shortlog | log | tree
>>> --
>>> Click "tree" on the master head line.
>>>
>>> In this case click "apps"
>>> --
>>> -rw-r--r-- 376684 app_queue.c blob | history | raw
>>> --
>>> Click "history" on the app_queue.c line.
>>>
>>> Typically a "segfault" fix will be in the commit message, so search in your
>>> browser.
>>>
>>> This exercise implies there are no upstream app_queue segfault fixes.
>>>
>>>
>>> This is a handy skill to have, particularly when an Asterisk issue is fixed
>>> in one version and not another.
>>>
>>> Lonnie
>>>
>>> PS, Armin's note of ASTERISK-25975 appears to be duplicate of
>>> ASTERISK-25888 which was fixed as noted above.
>>>
>>> On Sep 21, 2017, at 2:22 AM, Michael Knill
>>> <michael.kn...@ipcsolutions.com.au> wrote:
>>>
>>>> Oh dear. My busiest system too. Thanks goodness for safe_asterisk
>>>>
>>>> Sep 21 14:07:44 3037-QGPSC-CM1 user.info kernel: asterisk[1110]: segfault
>>>> at 10 ip 00002b1ed1d4882c sp 00002b1ed728fcd0 error 4 in
>>>> app_queue.so[2b1ed1d34000+35000]
>>>> Sep 21 14:07:45 3037-QGPSC-CM1 user.info safe_asterisk: Asterisk exited on
>>>> signal 11.
>>>>
>>>> Any ideas?
>>>> Can I get a backtrace from Astlinux?
>>>>
>>>> Regards
>>>> Michael Knill
>>
>> Michael
>>
>> http://www.mksolutions.info
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
