FreePBX Parking and Web Interface not working
-
Every few days I get in and my users report that they're not able to park and retrieve calls. Whenever this happens I get the following screen when I try to log into the web interface.
I also almost always have a cron error on my dashboard even when things seem to be working fine. I've done a little searching and I haven't come up with anything for that either. Once I'm able to reboot (20 min or so) I will post the cron error.
https://i.imgur.com/7M51fXw.png
Edit: This is self hosted and the interface is not public facing.
-
That error tells us that MySQL is either down or not accepting connections (which is effectively the same thing).
-
How are you handling call parking?
-
@jaredbusch said in FreePBX Parking and Web Interface not working:
How are you handling call parking?
Transfer to parking lot extension 70, which does actually work, but the BLFs don't light up on the phones showing that there is a parked call on the extension, so my users don't know that it's actually parked. On our phones there is a park button which transfers to 70, then we have 4 BLF for ext. 71-74 to indicate that there is a call on that extension.
Edit: actually it parks the call, and the BLF DOES work, but when they hit the button for ext 71, it says "there is no call on this extension" or something like that.
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@jaredbusch said in FreePBX Parking and Web Interface not working:
How are you handling call parking?
Transfer to parking lot extension 70, which does actually work, but the BLFs don't light up on the phones showing that there is a parked call on the extension, so my users don't know that it's actually parked. On our phones there is a park button which transfers to 70, then we have 4 BLF for ext. 71-74 to indicate that there is a call on that extension.
So, when call parking is "broken" what you actually mean to say is the BLF subscriptions are not working.
Totally different thing.
Manually park a call by transferring to 70 and listening for the park slot used.
Dial the park slot and pick up the call.If this works, then you know 100% that call parking is functioning normally.
-
@jaredbusch Sorry, I misinterpreted the problem. If I manually transfer to 70, it says "call parked on 71", the BLF lights up for 71, then when I actually hit the button for 71, or dial 71, the freepbx lady tells me that "there is no call on this extension"
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@jaredbusch Sorry, I misinterpreted the problem. If I manually transfer to 70, it says "call parked on 71", the BLF lights up for 71, then when I actually hit the button for 71, or dial 71, the freepbx lady tells me that "there is no call on this extension"
Okay, that means you need to know where the call went. Is the caller on hold someplace? If so, just dial each park until you find it.
If not, we can assume that transfer to parking disconnected the call.You can monitor this from the CLI (
asterisk -rvvvvv) if the PBX is not very busy. If it is busy, you will want togrepthe log file for the call. -
@jaredbusch said in FreePBX Parking and Web Interface not working:
You can monitor this from the CLI (asterisk -rvvvvv) if the PBX is not very busy. If it is busy, you will want to grep the log file for the call.
-
-
The MySQL issue and the Call park issue should be totally unrelated.
Asterisk does not use MySQL for anything.
FreePBX uses it to store the configs to send to Asterisk and all, but normal operation has nothing to do with MySQL.
To resolve your mysql issues, simply restart it.
On FreePBX 13 and older:service mysql start
On FreePBX 14 and newer:systemctl start mysql -
@bnrstnr said in FreePBX Parking and Web Interface not working:
@jaredbusch said in FreePBX Parking and Web Interface not working:
You can monitor this from the CLI (asterisk -rvvvvv) if the PBX is not very busy. If it is busy, you will want to grep the log file for the call.
So this says the call went to park slot 71 and the hold music started playing.
If you do this, and then then dial 71 (don't use a BLF), what does the log show? -
@jaredbusch said in FreePBX Parking and Web Interface not working:
On FreePBX 14 and newer: systemctl start mysql
systemctl start mariadb at least stopped the notification every 30 seconds, not sure what is causing it though, I'll dig through some log files.
-
@jaredbusch said in FreePBX Parking and Web Interface not working:
If you do this, and then then dial 71 (don't use a BLF), what does the log show?
The MySQL issue and the Call park issue should be totally unrelated.
Maybe it's coincidence, but as soon as I restarted mariadb, dialing 71 and the BLF both pick up the parked extension perfectly fine again.
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@jaredbusch said in FreePBX Parking and Web Interface not working:
If you do this, and then then dial 71 (don't use a BLF), what does the log show?
The MySQL issue and the Call park issue should be totally unrelated.
Maybe it's coincidence, but as soon as I restarted mariadb, dialing 71 and the BLF both pick up the parked extension perfectly fine again.
That's just odd, like mariadb isn't getting started like it should.
If you type
systemctl enable maraiadb, what's the output? -
@travisdh1 no output
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@travisdh1 no output
Then I was wrong about mariadb not being set to automatically start, it already was. Do you see anything in the log files on why it stops?
-
It looks like it may have been permission issues? Do you guys know if amportal was ever used in FPBX14, or has it always been fwconsole?
I haven't had any issues, even after multiple reboots, since running 'systemctl start mariadb', but I also ran 'fwconsole chown' during that same session, so maybe that is what cured these issues? I'm not sure, but I will keep digging.
-
Pretty much this... over and over
170717 16:11:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 170717 16:11:45 [Note] /usr/libexec/mysqld (mysqld 5.5.52-MariaDB) starting as process 3996 ... 170717 16:11:45 InnoDB: The InnoDB memory heap is disabled 170717 16:11:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins 170717 16:11:45 InnoDB: Compressed tables use zlib 1.2.7 170717 16:11:45 InnoDB: Using Linux native AIO 170717 16:11:45 InnoDB: Initializing buffer pool, size = 128.0M 170717 16:11:45 InnoDB: Completed initialization of buffer pool InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 170717 16:11:45 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 170717 16:11:45 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 170717 16:11:45 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: 127 rollback segment(s) active. InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 170717 16:11:45 InnoDB: Waiting for the background threads to start 170717 16:11:46 Percona XtraDB (http://www.percona.com) 5.5.49-MariaDB-38.0 started; log sequence number 0 170717 16:11:46 [Note] Plugin 'FEEDBACK' is disabled. 170717 16:11:46 [Note] Server socket created on IP: '0.0.0.0'. 170717 16:11:46 [Note] Event Scheduler: Loaded 0 events 170717 16:11:46 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.52-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server 170717 16:23:13 [Note] /usr/libexec/mysqld: Normal shutdown 170717 16:23:13 [Note] Event Scheduler: Purging the queue. 0 events 170717 16:23:17 InnoDB: Starting shutdown... 170717 16:23:17 InnoDB: Waiting for 1 pages to be flushed 170717 16:23:21 InnoDB: Shutdown completed; log sequence number 68929652 170717 16:23:21 [Note] /usr/libexec/mysqld: Shutdown complete -
I don't know what you did but none of this is normal.
Was this a clean 14 install?
-
@jaredbusch This was a clean install of 14, I used the convert script (sometime in July, 2017) to migrate extensions, and the like, over from Elastix to 14. Since migrating from Elastix to 14, everything has been great until fairly recently, I don't know if some updates broke something, something in the OS was corrupted some how? I don't know.
Do you think it would be beneficial to spin up a new instance of 14 and migrate everything over again?
