hyperlink issue - loadURL is not defined after upgrade from 1.1.6 to 1.2.17

[jmasloske]

Greetings! I am having an issue after upgrading where clicking on the hyperlink for additional web pages (graphs section, creating new graphs for a device) does not work. I have tried multiple browsers and cleared cache to no avail. In the example in this message, I did a right click and then "Inspect" on the page "2". Attached is a PDF with the error. I have searched the forums and I am unable to find anyone describing the issue.

Also attached is the plan we followed. There were some rights issues that were corrected. but I do not recall all of them. I believe there may still be some rights issues as I get an error message for "website does not have write access to folder message" when creating new graphs. Not sure if this might be part of my issue. Thanks for reading and let me know if you have any ideas on how to fix.

[macan]

chown -R apache:apache /rra

[jmasloske]

Root was the owner of /RRA, and that has been corrected. However, I am still getting the loadURL error. I can't click pages "2-7" on the web page, or "Next". Anybody have any idea on how to fix?

loadURL is not defined.pdf

(91.06 KiB) Downloaded 48 times

[camerabob]

Tried clearing the browser cache or another browser?

[pcowand]

Hi,

I've been working with Jim from the Linux Admin side. We have tried it on multiple PC's and see the issue (doubt browser based issue). We have changed the permissions to multiple variations: apache:cacti (1.1.6 setting), cacti:cacti, and now apache:apache. No changes in behavior for any of them.

The issue we are currently fighting is that when you click on Next or the next number in the array for a page does nothing but stay on the same page. For the graphs, if we change the number of graphs per page, they all show up fine. This issue is on the graphs, log files and any other page that does not fit on a single screen. Seems like it might be a php code issue, but not a php code specialist that could go in and debug it.

[netniV]

This sounds like you may have cross pollenation going on between your instances, check the host URLs are the correct ones as well.

[jmasloske]

Hi netniV. Thank you for taking the time to review my post and respond.

Where would I check to correct? It's broken for cacti.log as well (and anything where there are additional pages). In this example I show I am trying to click page 2. The URL being referenced shows up below in the example. The URL in this example looks similar to what I have on a Cacti server using ver 1.1.6. where additional pages are working.

2022-02-25_11-22-03.png (139.83 KiB) Viewed 1097 times

[netniV]

You have a few issues going on with your system as it also looks like it's trying to load the MySQL module more than once and that's at a PHP level, not Cacti.

I would check that you don't have multiple apache configurations / PHP configurations being applied and that any other folders containing instances of Cacti are moved to prevent inclusion.

[jmasloske]

Thank you, netniV. I have spent quite a bit of time trying to figure out where the MySQL module is being loaded more then once with no luck. I believe my config.php file looks good. I don't have any other instances of cacti on this server, but there is a folder at root level named cacti for plugins testing. Any suggestions on what / where to look for were MySQL is being referenced, or is there a level of debugging I can enable that might help me figure out where MySQL has the multiple references?

For the record, similar error messages are also showing up on the original server running 1.1.6. So i believe these errors showing up in the log are likely not the source of the loadURL issue since I don't have the page issue on 1.1.6 The old server running 1.1.6 is referencing functions.php. Could the source of the log error messages be in this file?

Attachment below is from server running 1.1.6.

2022-03-01_9-20-01.png (70 KiB) Viewed 1080 times

[macan]

which operating system? Show part of php.ini, lines begin "extension="

[jmasloske]

macan - you pointed me in the right direction. Someone had added "extension=mysql.so" to the php.ini file, but this is being loaded automatically by the packaged extension module in /etc/php.d. Here is how my php.ini config looks now after I commented this section out:

; If you only provide the name of the extension, PHP will look for it in its
; default extension directory.
; Someone added next two lines 11/2017, but only "extension=mysql.so" was active on 3/15/22. Jim M. disabled "extension=mysql.so" in this file only on 3/15/22
; extension=mysql.so
; extension=snmp.so
; both lines previously added above 11/2017 are not needed and caused errors in log file. These are loaded by default from packaged extension discussed below in directory /etc/php.d

This has helped clean up my log file error messages quite a bit, but not all the way. Seems that by disabling the extension module in php.ini that I no longer receive the error message for "Module 'mysql' already loaded" on the "5's" when polling occurs, but I sometimes still get the same error message in between polling cycles. I checked all packaged extensions in /etc/phpd and do not find references to mysql.so anywhere there. I also do not find any references to mysql.so anywhere in php.ini. Any other ideas on where this might still be referenced?

*** Update *** I went three polling cycles without seeing the ERROR PHP CORE_WARNING for "Module 'mysql' already loaded in file: Unknown on line:0", but it just popped up again. It seems to be quite random.

mysql_CMD_ERROR.jpg (512.6 KiB) Viewed 1042 times

[macan]

maybe more than one php.ini in your system. Try locate php.ini.
You can run php_info() for more information