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.
-
-
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?
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@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.
That is NOT a clean install.
That is a migration.
That script does a LOT of backend stuff that I have had trouble with more than one time.
I have given up and will only do a true clean install and manual migration anymore.
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
Do you think it would be beneficial to spin up a new instance of 14 and migrate everything over again?
I would spin up a new instance.
But I would not use a migration script.
I would export things since you are on FreePBX 14 and are going to FreePBX 14. You have this power now.
I don't have time to grab screenshots, but the export import functions do work.
-
@jaredbusch said in FreePBX Parking and Web Interface not working:
I would export things since you are on FreePBX 14 and are going to FreePBX 14. You have this power now.
Ah yes, didn’t even think about this. Good call!
-
@JaredBusch Do you recommend sticking with Asterisk 13 on the new install or should I go with 15?
-
@bnrstnr said in FreePBX Parking and Web Interface not working:
@JaredBusch Do you recommend sticking with Asterisk 13 on the new install or should I go with 15?
Not tested 15 yet, so I cannot answer that from experience. I can say that I’ve never had a problem caused by Asterisk
-
I guess since 13 is the LTS and still the default option on the installer I'll go with that
-
@jaredbusch said in FreePBX Parking and Web Interface not working:
@bnrstnr said in FreePBX Parking and Web Interface not working:
@JaredBusch Do you recommend sticking with Asterisk 13 on the new install or should I go with 15?
Not tested 15 yet, so I cannot answer that from experience. I can say that I’ve never had a problem caused by Asterisk
Same here, using 13 because FreePBX is recommending it right now. But doubt 15 would be an issue.
