Asterisk 1.8 package
-
The package should generate a simple rc-file with the name asterisk, such that the manual boot time service does not get called.
What second instance? The /usr/local/etc/rc.d/asterisk script is removed on install.
https://github.com/pfsense/pfsense-packages/blob/master/config/asterisk/asterisk.inc#L41
-
Nope, the file asterisk never gets generated, only asterisk.sh. And this causes the problem of two instances.
-
Nope, the file asterisk never gets generated, only asterisk.sh. And this causes the problem of two instances.
And it should NOT get generated. The only file that SHOULD exist is asterisk.sh. If you still have /usr/local/etc/rc.d/asterisk, just reinstall the package. (And, in general, do yourself a favor and do not upgrade packages on pfSense <2.3, uninstall and reinstall them instead. Otherwise, the updated install code simply is not used.)
-
I think currently only asterisk.sh gets installed. asterisk.sh causes problems. I have to setup a new box tomorrow and then I'll have a look at what happens at a fresh install.
<service>.sh should only be used for manual services outside any package. At least that's my understanding. Just have a look at rc.start_packages. Essentially $rcfiles = glob(RCFILEPREFIX . "*.sh"); grabs all .sh files and if a package uses the .sh extension itself; one potentially runs into problems if an executable cannot detect that another instance has already been started.</service>
-
Sigh.
1/ <service>.sh is used by pretty much any package out there. Usually generated by write_rcfile(). The scripts bundled with the PBI packages are NOT usable.
2/ As already noted 3 times, you should NOT have any /usr/local/etc/rc.d/asterisk script in there. If you have, then delete it or reinstall the package and it will delete is on install.</service> -
The asterisk script is not generated, only asterisk.sh, but this script is called two times during system startup. Since Asterisk cannot detect almost parallel invocations, two instances are typically running. That's a problem. Therfore I suggested to give the first invocation a chance to get fully booted.
If you don't believe me, insert a "logger" statement in asterisk.sh to see that "start" it is called twice at system startup.
-
FFS!!!! Your issue is having TWO scripts when you should have one, and that one should be called asterisk.sh. Reinstall the package or delete it manually. Explained 4 times by now. >:(
Period.
-
There's only asterisk.sh, and this script gets called twice.
-
Yeah, so get it fixed in pfSense core. Every damn package out there uses what I already explained.
-
Hoops! There was an "asterisk" script withoug the .sh extension…
-
Incredible. Won't explain for the fifth time. Pretty much every package out there uses <something>.sh with no problem. If you have issue with something called twice, then fix the code that's calling something twice.
And - while here… that pfSense core code show grow itself some brain and produce an API for disabling packages. Instead of people hacking code that creates the script on enabling the package and remove it on disabling. rc.conf.local ain't usable for this, perhaps/etc/rc.conf.d/ could.</something>
-
I just started a fresh 2.2.5 install (virtual machine) and the default installation starts Asterisk twice as described here:
https://forum.pfsense.org/index.php?topic=102591.0
asterisk.sh gets called twice and there are no old installations and there is no single asterisk script in the rc.d dir. A couple of days ago I added a logger() statement in asterisk.sh and the script was indeed called twice, which explains the two instances.Tomorrow I'll setup a new machine and then I'll report again. I have about half a dozen 2.2.4 boxes with older installations, so I cannot exclude that there are still asterisk scripts or whatever, like the one I checked about an hour ago.
-
Initially asterisk.sh gets called in the background and the .sh loop calls it directly, so a short sleep may or may not solve the problem.
I am too tired now, but my basic idea is that anything that gets called in the background with start_service(), will not get called subsequently. Should be easy to implement.
-
I am too tired now, but my basic idea is that anything that gets called in the background with start_service(), will not get called subsequently. Should be easy to implement.
Kindly post the output of the following (paste to Diagnostics - Command Prompt - PHP execute)
require_once("/etc/inc/pkg-utils.inc"); $rcfiles = glob(RCFILEPREFIX . "*.sh"); if (!$rcfiles) $rcfiles = array(); else { $rcfiles = array_flip($rcfiles); if (!$rcfiles) $rcfiles = array(); } if (is_array($config['installedpackages']['package'])) { foreach($config['installedpackages']['package'] as $pkgid => $package) { $internal_name = get_pkg_internal_name($package); unset($rcfiles[RCFILEPREFIX . strtolower($internal_name) . ".sh"]); } } var_dump($rcfiles);since whatever you are describing simply doesn't happen with sane configuration. The .sh script just won't run from the $shell = @popen("/bin/sh", "w"); part because it's unset with the
unset($rcfiles[RCFILEPREFIX . strtolower($internal_name) . ".sh"]);line.
-
https://github.com/pfsense/pfsense-packages/pull/1191 should fix whatever is fixable in the package regarding service (re)starts.
-
Kindly post the output of the following (paste to Diagnostics - Command Prompt - PHP execute)
I see this only briefly flashing on the console. Are these messages also written into some file?
-
Console?! Diagnostics - Command Prompt - PHP execute is not briefly flashing anywhere. Regardless, the PR has been merged.
-
One can call log_error() to show things on the console, which I used for my tests. I also saw a couple of echos in rc.start_packages, but I did not check where the output is going (probably nowhere, without a web interface). The same would apply to your var_dump() call.
I could explicitly call rc.start_packages and rc.stop_packages, but I don't know whether this is equivalent to what happens at boot time. It will take some time before I've studied all the php stuff….
-
I would suggest installing 0.3.4 before wasting more time here.
-
Can the Asterisk package meanwhile work as an endpoint for T.38 faxes? No? My custom package does. There's nothing in the GUI that depends on the specific Asterisk version, so why is 1.8 used? No hangup handlers, no named ACLs, no AMI security events, no RESTful interface, but a lot of useless modules. Maybe it is you who should not waste time with Asterisk. Have you figured out meanwhile why a B2BUA makes sense in a firewall?