Having run net/asterisk13 with a simple config (nothing fancy) moving to net/asterisk15 seemed smooth. But there is a very strange behaviour regarding the rc script controlling "service asterisk15 restart" and sibblings. Running net/asterisk15 on CURRENT (12.0-CURRENT #64 r331494: Sat Mar 24 20:31:34 CET 2018amd64). The weird thing is the following. On the console of the PBX, type: [...] # service asterisk restart Stopping asterisk. Asterisk 15.3.0, Copyright (C) 1999 - 2016, Digium, Inc. and others. Created by Mark Spencer <markster@digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. ========================================================================= Running as user 'asterisk' Running under group 'asterisk' Connected to Asterisk 15.3.0 currently running on gate (pid = 995) gate*CLI> quit Asterisk cleanly ending (0). Executing last minute cleanups Waiting for PIDS: 995 [...] It seems, the rc script let me jump immediately into Asterisk's console. trying to leave the Asterisk 15 console, leaves me in eternity with the "Waiting for PIDS: XXX". I can escape this issue with performing a "core reload". Typing then QUIT or EXIT performs as expected. It doesn't matter what "service asterisk"-command I issue, it always jumps into Asterisk's console.
I'll be looking at this. Thanks for reporting.
I've been able to reproduce this. Doing some diffs on the sources shows the processing of command line arguments using getopt has been heavily modified between versions 13 and 15. I assume these changes to command line options parsing are causing the -x option (used by the rc script to pass commands to the asterisk daemon via the remote console) to not work as it used to. I need some time to investigate the changes and understand how they break things and find a fix. My first guess is getopt on FreeBSD and linux behave slightly different and that's' the min cause, but I cannot be sure until I'm done studying the situation.
A commit references this bug: Author: madpilot Date: Mon Mar 26 11:13:14 UTC 2018 New revision: 465580 URL: https://svnweb.freebsd.org/changeset/ports/465580 Log: Fix asterisk 15 command line parsing. PR: 226909 Submitted by: O. Hartmann <ohartmann@walstatt.org> Changes: head/net/asterisk15/Makefile head/net/asterisk15/files/patch-main_asterisk.c
I found the cause. My initial suspicion was confirmed. For the record, the asterisk code in asterisk15 is calling getopt(3) two times in a row. To make this work they need to reset the "optind" variable, they do it here at [1], setting the value to 0. This is a mistake. glibc implementation of getopt forces that 0 value to 1 at [2], while our implementation does not have such a check. Using optind = 0 causes our getopt to check if argv[0] (the command being run, in this case usually "asterisk" or "rasterisk") is an option, by checking if it starts with a '-' at [3], which is not the case, causing getopt to exit early without performing the second round of command line parsing. Changing the asterisk code to use "optind = 1" fixes the issue. [1] https://github.com/asterisk/asterisk/blob/f13131b5cdee219841cc767e01101472ebd46606/main/asterisk.c#L3998 [2] https://github.com/bminor/glibc/blob/2d813d7b77ba8341a0a982d74bb59f5a0d775784/posix/getopt.c#L387 [3] https://github.com/freebsd/freebsd/blob/5c40d602eef148e8d4231cda313ea122738096f4/lib/libc/stdlib/getopt.c#L72
Thank you very much for investigating the problem so fast and thorough. oh
Just for the record, I've submitted the change upstream and it's going through their code review process, it should be accepted upstream in the next few days.