OK, I found where the config_boot_linux() which is causing me problems is called from (I had not initially realized there were multiple calls to it) and on a Linux system it is called unconditionally with no way of turning it off so I commented it out…
(It is on line 504 of /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl with the version of Wanpipe I have…)
Since commenting out that line didn’t remove the chkconfig on entry I disabled it one last time with
chkconfig wanrouter off
Everything seems to work perfectly and consistently and my system has already gone quite a few reboots ad things are always correctly initialized…
I only have two small problems which occasionally appear when I SSH to my system and for at least one of them I believe I know the cause…
One of them is this:
Exception: SQLSTATE[HY000] [2002] No such file or directory::SQLSTATE[HY000] [2002] No such file or directory in file /var/www/html/admin/libraries/utility.functions.php on line 204
Stack trace:
1. Exception->() /var/www/html/admin/libraries/utility.functions.php:204
2. die_freepbx() /var/www/html/admin/libraries/BMO/Database.class.php:154
3. PDOException->() /var/www/html/admin/libraries/BMO/Database.class.php:149
4. PDO->__construct() /var/www/html/admin/libraries/BMO/Database.class.php:149
5. FreePBX\Database->__construct() /var/www/html/admin/libraries/BMO/FreePBX.class.php:69
6. FreePBX->__construct() /var/www/html/admin/bootstrap.php:151
7. require_once() /etc/freepbx.conf:9
8. include_once() /var/lib/asterisk/bin/fwconsole:12
Exception: SQLSTATE[HY000] [2002] No such file or directory::SQLSTATE[HY000] [2002] No such file or directory in file /var/www/html/admin/libraries/utility.functions.php on line 204
Stack trace:
1. Exception->() /var/www/html/admin/libraries/utility.functions.php:204
2. die_freepbx() /var/www/html/admin/libraries/BMO/Database.class.php:154
3. PDOException->() /var/www/html/admin/libraries/BMO/Database.class.php:149
4. PDO->__construct() /var/www/html/admin/libraries/BMO/Database.class.php:149
5. FreePBX\Database->__construct() /var/www/html/admin/libraries/BMO/FreePBX.class.php:69
6. FreePBX->__construct() /var/www/html/admin/bootstrap.php:151
7. require_once() /etc/freepbx.conf:9
8. include_once() /var/lib/asterisk/bin/fwconsole:12
(Yep, it does appear twice…)
I believe this is from the motd-like message we see when we remote our systems…
I believe this happens because now that the boot is much faster I am sometimes able to remote my system before MariaDB is up. This FreePBX code is pretty unhappy with that and complains…
The other is a complaint from System Admin about not being able to do a mkdir…
I guess this too could be caused by database access before MariaDB is up…
The query to get something needed for this mkdir most likely fails and the path to create improperly initialized and mkdir is unhappy with whatever it got asked to create…
I asked myself why are the Wanpipe scripts requiring to be started at boot since it causes so much problems and then it hit me…
Just like those drivers are not required to use their DAHDI compatibility mode because they support other means of being talked to, what they would be used with it not assumed either…
We use it with FreePBX/Asterisk but the drivers/cards could be used with something else so not depending on that something else to later initialize the drivers by doing it during boot is a good idea.
There is now a problem with starting them before network is up but except for this, it looks like there are use cases where starting wanrouter at boot is a good thing…
Now it sounds to me that something needs to be added to those drivers so that it possible to configure them not to setup things so that they start at boot when used with FreePBX.
In the mean time, I did this:
if ($os_type_list =~ m/FreeBSD/){
config_boot_freebsd();
} else {
# config_boot_linux();
}
(ie comment out config_boot_linux() at line 504 of /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl with the version of Wanpipe I have…)
to address the specific problem I have…
I will keep you posted but right not this seems to have done the trick… It did make me uncover what appears to be a much smaller problem with the motd-like message when I remote my system but that seems to be caused by trying to access the database before it is up…
Have a nice day!
Nick