Anyone got any idea why ‘/etc/init.d/dahdi status’ and ‘systemctl status dahdi’ would give different results on boot? I thought this was the smoking gun!
It’s not the smoking gun because /etc/init.d/dahdi status redirects to systemctl status dahdi.
If that’s the case why do I get different results between ‘/etc/init.d/dahdi status’ and ‘systemctl status dahdi’?
After a reboot, ‘dahdi status’ echo $? reports 0, whereas ‘systemctl status dahdi’ echo $? reports 3.
If I then manually start dahdi, both report 0.
Could it be that ‘dahdi status’ it’s not redirecting correctly on my system?
Thanks for your continued support and patience with me.
This is as much a note to myself, and anyone else having a similar problem, on how to get DAHDi running after a reboot.
Basically, after reboot, I need to manually run the follow to get DAHDi running:
[root@freepbx ~]# service dahdi start
Starting dahdi (via systemctl): [ OK ]
[root@freepbx ~]# fwconsole restart
I would still like to understand why ‘dahdi status’ echo $? reports 0, whereas ‘systemctl status dahdi’ echo $? reports 3 after a reboot. I’m sure this is why DAHDi isn’t automatically loading on my system at start (the script thinks it’s running already).
2 Likes
i have the same problem, and the same solution, execute this 2 lines.
its any chance to add this 2 lines to any file, so when the pbx start execute automatically
[root@freepbx ~]# service dahdi start
Starting dahdi (via systemctl): [ OK ]
[root@freepbx ~]# fwconsole restartI’ve just finished a fairly large System Update, and this has solved the problem for me. Here is my new version details:
Current PBX Version:14.0.1.15
Current System Version:12.7.3-1708-1.sng7
Total Module Count:119
Enabled:117
Edit: Further update to dahdi & wanpipe today, and it seems to be broken again 
how do you make this update???
i check and not see nothing
From the Web GUI: Admin / Updates / System Updates / Check Online. This might break your GUI. If it does, there’s a thread that discusses the problem, and identifies the fix here:
Alternatively, try yum check-update from the command line.
Right. I think we’ve got this sorted now. Discussion had moved to another thread for some reason, but the solution was fairly straight forward in the end!
Before running the command above I did a quick check with chkconfig --list | grep -i wanrouter which gave the following
[root@freepbx ~]# chkconfig --list | grep -i wanrouter
Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.
If you want to list systemd services use 'systemctl list-unit-files'.
To see services enabled on particular target use
'systemctl list-dependencies [target]'.
wanrouter 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@freepbx ~]#
Turns out this probably was the real fix…
All working perfectly now :).
Not to start it at boot I think is but not the way I suggested you do it temporarily for now…
The Wanpipe scripts are actually setting things up that way…
If I try to do the same thing I told you to do
ie
chkconfig wanrouter off
I get one or two error messages (which relatively seem harmless and which you apparently did not get so it’s probably specific to my Sangoma Wanpipe card) but it doesn’t stick…
It takes a while before everything gets initialized but once it is done everything works beautifully…
Unfortunately, it only survives one boot…
There is code in /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl (see [FREEPBX-15491] FreePBX 13 to 14 upgrade fails - Upgrade loops apparently because of lack of DNS resolution - Sangoma Issue Tracker for more information) which actually reenables wanrouter to start at boot…
Since you do not have a card which uses Wanpipe this bit of code hopefully does not get run (if it did things would have went back to the way they were before after one reboot) but for someone like me which has a card which does use Wanpipe the fix I suggested you do will not work for them (unless they reapply it over and over again…).
So for now only consider this a workaround and to everyone else, if you have a card which uses Wanpipe, don’t bother doing this as it will not survive a reboot…
Have a nice day!
Nick
Guys,
Just wanted to say thanks for posting up this thread with your detailed issues and the solutiuon. I’ve just upgraded a perfectly working server (from 10.13.66 to SNG7) and whilst the upgrade went well, I had the same problem with an OpenVox B410 BRI card failing to be seen by FreePBX. Switched off wanrouter in chkconfig and box is now booting happily and initialising the card sucessfully.
Thanks to you and everyone else who takes time to provide help and support on these forums, it’s greatly appreciated.
Cheers !