Upgrade to FreePBX 14 from 13 failing

How can I check this?

Thats not the issue. He runs fwconsole stop and then it says it stopped dahdi then he runs fwconsole start and it says it’s already running. At this scope its outside the scope of systemd. Also it’s returning exit code 0 after it’s already been told to stop.

The commands that the module runs are

/etc/init.d/dahdi stop
/etc/init.d/dahdi status
/etc/init.d/dahdi start

The output of status is an exit code retrieved from running echo $? after the command is executed.

When exit code is === 3 then start is run. if exit code is === 0 then dahdi is already running.

[[email protected] zulu]# /etc/init.d/dahdi status
[[email protected] zulu]# echo $?
0
[[email protected] zulu]# /etc/init.d/dahdi stop
Unloading DAHDI hardware modules: done
[[email protected] zulu]# /etc/init.d/dahdi status
[[email protected] zulu]# echo $?
3
[[email protected] zulu]# /etc/init.d/dahdi start
Loading DAHDI hardware modules:
  wct4xxp:                                                 [  OK  ]
  wcte43x:                                                 [  OK  ]
  wcte12xp:                                                [  OK  ]
  wcte13xp:                                                [  OK  ]
  wct1xxp:                                                 [  OK  ]
  wcte11xp:                                                [  OK  ]
  r1t1:                                                    [  OK  ]
  rxt1:                                                    [  OK  ]
  wctdm24xxp:                                              [  OK  ]
  wcaxx:                                                   [  OK  ]
  wcfxo:                                                   [  OK  ]
  wctdm:                                                   [  OK  ]
  rcbfx:                                                   [  OK  ]
  wcb4xxp:                                                 [  OK  ]
  wctc4xxp:                                                [  OK  ]
  xpp_usb:                                                 [  OK  ]

Running dahdi_cfg:                                         [  OK  ]
[[email protected] zulu]# echo $?
0

Status codes of 0 or 3 are determined by the following code in /etc/init.d/dahdi

    if [ -d /proc/dahdi ]; then
            /usr/sbin/lsdahdi
            RETVAL=0
    else
            RETVAL=3
    fi

This part of the code checks if the folder /proc/dahdi exists. If it does then it executes /usr/sbin/lsdahdi

Looks like dahdi stop isn’t working correctly:

[[email protected] ~]# /etc/init.d/dahdi status
### Span  1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
  1 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)
  2 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  3 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  4 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)  RED
[[email protected] ~]# echo $?
0
[[email protected] ~]# /etc/init.d/dahdi stop
Stopping dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# /etc/init.d/dahdi status
### Span  1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
  1 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)
  2 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  3 FXS        FXOKS       (In use) (EC: OSLEC - INACTIVE)
  4 FXO        FXSKS       (In use) (EC: OSLEC - INACTIVE)  RED
[[email protected] ~]# echo $?
0
[[email protected] ~]# /etc/init.d/dahdi start
Starting dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# echo $?
0
[[email protected] ~]#

Why might that be? Could it be that I do have two instances of dahdi running, as @tonyclewis has suggested?

Also, when I’m stopping and starting dahdi, it’s being done via systemctl on my system. This is different to what @tm1000 is reporting. Why would that be? I don’t see the text ‘Loading DAHDI hardware modules’ when I start DAHDI, although I can see this text in the /etc/init.d/dahdi script file.

Because I am showing how it works on CentOS 6.6 we are already discussing this. At this time it seems like a Digium issue with dahdi-tools in CentOS 7

Ah. ok. I also made a further edit to my previous post, but your response probably answers that too. Really appreciate your support on this.

Unfortunately I can no longer replicate the issue on my Sangoma 7 distro.

/etc/init.d/dahdi redirects to systemd and that works 100% fine.

In fact both commands work fine now. It’s not a digium issue it appears to be an issue with your unsupported card I think.

[[email protected] ~]# /etc/init.d/dahdi start
Starting dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# /etc/init.d/dahdi stop
Stopping dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
3
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
3
[[email protected] ~]# systemctl stop dahdi
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: inactive (dead) since Tue 2017-08-15 16:27:09 PDT; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 22523 ExecStop=/etc/rc.d/init.d/dahdi stop (code=exited, status=0/SUCCESS)
  Process: 22386 ExecStart=/etc/rc.d/init.d/dahdi start (code=exited, status=0/SUCCESS)

Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: wctdm:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: rcbfx:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: wcb4xxp:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: wctc4xxp:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: xpp_usb:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com dahdi[22386]: Running dahdi_cfg:  [  OK  ]
Aug 15 16:26:57 freepbxdevxxxxx.com systemd[1]: Started LSB: DAHDI kernel modules.
Aug 15 16:27:07 freepbxdevxxxxx.com systemd[1]: Stopping LSB: DAHDI kernel modules...
Aug 15 16:27:09 freepbxdevxxxxx.com dahdi[22523]: Unloading DAHDI hardware modules: done
Aug 15 16:27:09 freepbxdevxxxxx.com systemd[1]: Stopped LSB: DAHDI kernel modules.
[[email protected] ~]# systemctl start dahdi
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: active (exited) since Tue 2017-08-15 16:27:20 PDT; 1s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 22523 ExecStop=/etc/rc.d/init.d/dahdi stop (code=exited, status=0/SUCCESS)
  Process: 22729 ExecStart=/etc/rc.d/init.d/dahdi start (code=exited, status=0/SUCCESS)

Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wctdm24xxp:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wcaxx:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wcfxo:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wctdm:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: rcbfx:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wcb4xxp:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: wctc4xxp:  [  OK  ]
Aug 15 16:27:19 freepbxdevxxxxx.com dahdi[22729]: xpp_usb:  [  OK  ]
Aug 15 16:27:20 freepbxdevxxxxx.com dahdi[22729]: Running dahdi_cfg:  [  OK  ]
Aug 15 16:27:20 freepbxdevxxxxx.com systemd[1]: Started LSB: DAHDI kernel modules.
[[email protected] ~]# echo $?
0
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
0

I can get the same (or very similar) response on my system. However, DAHDI still isn’t starting correctly on boot, and by doing a few things in a different sequence, I can get myself into a position where I can’t stop DAHDI after having started it. Whilst it may be a compatibility issue with my card, all I can say is that it worked perfectly before I tried to upgrade.

[[email protected] ~]# /etc/init.d/dahdi start
Starting dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# /etc/init.d/dahdi stop
Stopping dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
3
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
3
[[email protected] ~]# systemctl stop dahdi
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: r1t1:  [  OK  ]
Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: rxt1:  [  OK  ]
Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: rcbfx:  [  OK  ]
Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: D: auto '/sys/bus/dahdi_devices/devices/pci:0000:03:00.0'
Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: auto-assign /sys/bus/dahdi_devices/devices/pci:0000:03:00.0
Aug 16 00:41:26 freepbx.xxx.co.uk dahdi[4237]: Running dahdi_cfg:  [  OK  ]
Aug 16 00:41:26 freepbx.xxx.co.uk systemd[1]: Started LSB: DAHDI kernel modules.
Aug 16 00:41:31 freepbx.xxx.co.uk systemd[1]: Stopping LSB: DAHDI kernel modules...
Aug 16 00:41:32 freepbx.xxx.co.uk dahdi[4354]: Unloading DAHDI hardware modules: done
Aug 16 00:41:32 freepbx.xxx.co.uk systemd[1]: Stopped LSB: DAHDI kernel modules.
[[email protected] ~]# systemctl start dahdi
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: active (exited) since Wed 2017-08-16 00:45:24 BST; 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4952 ExecStart=/etc/rc.d/init.d/dahdi start (code=exited, status=0/SUCCESS)

Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: wcb4xxp:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: wctc4xxp:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: xpp_usb:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: r1t1:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: rxt1:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: rcbfx:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: D: auto '/sys/bus/dahdi_devices/devices/pci:0000:03:00.0'
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: auto-assign /sys/bus/dahdi_devices/devices/pci:0000:03:00.0
Aug 16 00:45:24 freepbx.xxx.co.uk dahdi[4952]: Running dahdi_cfg:  [  OK  ]
Aug 16 00:45:24 freepbx.xxx.co.uk systemd[1]: Started LSB: DAHDI kernel modules.
[[email protected] ~]# echo $?
0
[[email protected] ~]# /etc/init.d/dahdi status
### Span  1: WCTDM/4 "Wildcard TDM400P REV I Board 5" (MASTER)
  1 FXO        FXSKS       (EC: OSLEC - INACTIVE)
  2 FXS        FXOKS       (EC: OSLEC - INACTIVE)
  3 FXS        FXOKS       (EC: OSLEC - INACTIVE)
  4 FXO        FXSKS       (EC: OSLEC - INACTIVE)  RED
[[email protected] ~]# echo $?
0
[[email protected] ~]#

Interestingly, ‘/etc/init.d/dahdi status’ and ‘systemctl status dahdi’ give different results on boot:

[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
0
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)
[[email protected] ~]# echo $?
3
[[email protected] ~]# /etc/init.d/dahdi status
[[email protected] ~]# echo $?
0
[[email protected] ~]# systemctl status dahdi
● dahdi.service - LSB: DAHDI kernel modules
   Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)
[[email protected] ~]# echo $?
3
[[email protected] ~]#

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:

[[email protected] ~]# service dahdi start
Starting dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# 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

[[email protected] ~]# service dahdi start
Starting dahdi (via systemctl):                            [  OK  ]
[[email protected] ~]# fwconsole restart

I’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 :frowning:

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

[[email protected] ~]# 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
[[email protected] ~]#

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 https://issues.freepbx.org/browse/FREEPBX-15491?focusedCommentId=110997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-110997 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 !