So here’s some more information now that I had a chance to take in more of this forum thread’s information. The ticket that @dicko pointed out was extremely helpful as it led to Nicolas’s ticket that provided a bunch of additional information as well as four other forum threads related to this issue and a good analysis to help isolate between possible dahdi and wanpipe issues.
Using this information, I was able to reproduce Nicolas’s (@Marbled) issue on a system with multiple dahdi cards loaded. His ticket was already queued up from this past Monday’s triage meeting to be investigated so I moved up it’s priority given the other forum posts and now this one that seemed to be the same or related.
I don’t know if we’ve completely figured this out, since I still don’t know why the other system couldn’t reproduce the same behavior, but it seems to possibly be related to multiple causes and may be dependent on both dahdi versions and in some cases wanpipe versions.
Two of the things I have done is to check if both dahdi and wanpipe are already running before starting them. That is because a distro is often (but not always) starting these up with services, and it appears that if told to start when already running, at least recent versions of both don’t always handle this very gracefully and stop or reset things. (Unlike Asterisk which, if you try to start it and it’s already running, it will tell you so much and exit…) Given this scenario, it means that if you don’t have these setup to run from a service at boot, then rebooting wouldn’t hurt you but if you do have it setup, then rebooting might result in this breaking you. To make things more confusing, if you have the services setup to run, but you don’t’ have the dahdiconfig module (or it’s disabled), then we won’t do anything and it will start fine. (Thank you again Nicolas, your ticket was like a rosetta stone in bringing this to light, and thank you @dicko for connecting this post to that ticket and all the other posts).
To add yet more complication to this, we also do a chown on ‘everything’ including the dahdi device files when you do an fwconsole start or restart. The chown code uses the proper advanced setting configurations for the device user and group, but those defaults appear to be wrong in Advanced Setting (they’re set to asterisk, they should be root on most systems). Whether this is really related or not isn’t clear yet and it would appear that the dahdi subsystem ends up anyhow resetting the ownership of these device files to be root as they’re suppose to be, at least on the system I tested.
@freak I closed your ticket because I couldn’t reproduce your situation. In hind site, I closed it prematurely and I’m sorry for that and any frustration it caused you. In my defense though, I really couldn’t reproduce the issue, and really did need you to take it to the forums to see if more would get flushed out there. Once I stumbled upon this post, I did go back and add a link in your ticket to it. (I’m usually pretty up on the forums so usually can spot this. Unfortunately, I was buried up to my eyeballs working other FreePBX tickets and was a little behind keeping up with the forums.) But as it turns out:
This is exactly what has happened, between the compilation of details that Nicolas put in his ticket, which combined experiences from multiple other forum threads that all had varying degrees of information and some great observations that he had, I was able to both reproduce this and the other reported issues, as well as know where to start looking for a solution.
There are still unknown’s here so I can’t say this is conclusively solved. There are a lot of systems out there that are still booting fine. I don’t know yet if it’s related to varying versions of dahdi and/or wanpipe, or cases where the dahdi module has been disabled or services have been disabled, or if there is some relation with the chown permissions and incorrect defaults of asterisk instead of root.
This post brought other issues up that I’ve also addressed as a result. We’ve changed the tooltip about app_confbridge so it’s clear you should be using it, and that app_meetme is deprecated for now. We’ve removed the chown on the dahdi devices since there’s really no good reason these should get in a broken state. It’s been in there for years, but probably hasn’t needed to be and to be safe, we’ll simply leave them alone unless we hear this has some different unknown consequence.