So if the solution to this problem is removing app_meetme, why isn’t this the solution to the bug ticket?
Responding to this is honestly pointless. I know it might seem like I’m trying to be a jerk, but I’m not. It seems like if you get a bit outspoken around here about some business decisions that are made or express disappointment or concern over a change in direction certain people get very offended, can’t take that criticism, and hold grudges. Or maybe I’m crazy. But whatever, it won’t change and I’ve given up caring about getting along. I don’t care if people don’t personally like me, I just want to see things get better.
Yes, I should spend my time (that my employer pays me for, to prove a point to the FreePBX team. I’m sure they would love that. As if we all aren’t busy enough.
I’ve worked ticketing systems. I know it gets annoying having tons of “open” tickets and people submitting crap. But IMO there have been a decent number of cases in the past few months of tickets being closed that shouldn’t be. They are bugs, even if you can’t reproduce it. I have run into no less then 5 reproducible bugs across 5 different installations in the past month (some in commercial modules even). I CONSTANTLY upgrade when new updates release. And I test ALL features of new releases. Where many other users of FreePBX, in my humble opinion, sit on old setups and use a small subset of its features.
I post in the forums about an issue since I’m told to basically stop submitting the bugs to the ticketing system and I get 1 response and that is it. Problem will not be solved that way. So whatever.
The guy posts a log which says exactly what the problem is. He gets told that random logs don’t help. Ticket gets closed. Now this bug (just because you can’t reproduce it doesn’t make it NOT a bug) will be discuss in this thread by me and him, you or one of the team will offer some comments. In the end it won’t be addressed.
Now I’ve got a meeting to get to and better things to do with my time. Have a nice day.
1 Like
The issue you are having is DAHDI not starting/restarting. The symptom is your paging broke since meetme depends on DAHDI being up (meetme needs a timing source which is provided by DAHDI.) The ‘workaround’ is to either restart DAHDI or use app_confgridge which does not require DAHDI. The root issue you’re reporting still exists on your system, that’s the issue that couldn’t be reproduced. So, where as an acceptable solution to your situation may very well be to switch to app_confbridge, there is something still going on with DAHDI.
That is why app_confbridge is NOT the solution to the ticket. Since we can’t reproduce the issue though, we closed the ticket as “can’t reproduce.” And for what it’s worth, a closed ticket doesn’t always remain closed. It’s closed at this point because without further information, steps to reproduce, etc. there is nothing more that we’ve currently decided we will do. Tickets are often reopened for various reasons. That could end up happening here.
I honestly had no idea this thread already existed. Sorry you feel the way you do.
People get offended when unsubstantiated claims get made as if they were fact, and then when confronted with providing the data to substantiate those claims, excuses are made. If you are going to make bold public claims, provide the actual data to substantiate them. If you are right, there are a lot of people, myself included, who would want to see change.
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.
2 Likes