[ZBX-12389] Error 500 when last accessed group is no longer available Created: 2017 Jul 18  Updated: 2018 Jan 07  Resolved: 2018 Jan 07

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Frontend (F)
Affects Version/s: 3.2.5
Fix Version/s: 3.4.6rc1, 4.0.0alpha2, 4.0 (plan)

Type: Problem report Priority: Minor
Reporter: Tim Jahn Assignee: Oleg Egorov (Inactive)
Resolution: Fixed Votes: 0
Labels: crash, frontend, usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS


Attachments: PNG File Zabbix Host Gone.png     Text File access_log_last_half_hour.txt     HTML File error_log     File latest.php     Text File latest.php.patch     HTML File ssl_error_log    
Team: Team B
Sprint: Sprint 21, Sprint 22, Sprint 23, Sprint 24
Story Points: 0.5

 Description   

If the last accessed Host group in "Monitoring -> latest data" no longer exists then an error 500 will be returned and the user account has to be deleted and re-created to regain access to this page. Note that this does NOT happen if only one host in a host group is deleted. When just a single host is deleted a user gets the expected result of a reset search page. This result happened in multiple browsers and multiple computers, confirming it was an account related problem.



 Comments   
Comment by Oleg Egorov (Inactive) [ 2017 Sep 18 ]

Hello, Tim, how I can reproduce this issue step by step.

If the last accessed Host group in "Monitoring -> latest data" no longer exists then an error 500 will be returned and the user account has to be deleted and re-created to regain access to this page. Note that this does NOT happen if only one host in a host group is deleted.

In description "Host group no longer exists", when host was removed. Sorry, if I something don't understand.

Comment by Tim Jahn [ 2017 Sep 18 ]

To reproduce:

Visit monitoring -> latest data
Do a search for a host group (For example - 2003 servers)
Now go to configuration -> host groups
Delete the group 2003 servers (from our example)
Now go back to monitoring -> latest data
You will now either get a blank white page or a page that says error 500 depending on your web browser. This appears to be because it tries to query "2003 servers" but it no longer exists - we just deleted it.

The only work around I have found to get back to the “latest data” page has been to delete and rebuild a profile that has gotten stuck like this.

Comment by Tim Jahn [ 2017 Sep 18 ]

Visit monitoring -> latest data
Do a search for a host group (For example - 2003 servers)
Now go to configuration -> host groups
Delete the group 2003 servers (from our example)
Now go back to monitoring -> latest data
You will now either get a blank white page or a page that says error 500 depending on your web browser.

The only work around I have found to get back to the “latest data” page has been to delete and rebuild a profile that has gotten stuck like this.

Comment by Oleg Egorov (Inactive) [ 2017 Sep 20 ]

Hello. Tim!
Can you test latest.php.patch

Comment by Tim Jahn [ 2017 Sep 20 ]

I found the file path for latest.php in my Zabbix Front End. Looks like it is at /var/www/html/zabbix/latest.php. I do not know how to apply the patch, I am not familiar with PHP. Further, this is a production environment with thousands of hosts so I would need to be sure any changes would not cause down time (or I would need to schedule the change for off hours).

Comment by Oleg Egorov (Inactive) [ 2017 Sep 20 ]

latest.php patched file

Comment by Tim Jahn [ 2017 Sep 20 ]

I renamed latest.php to latest.old.
I created a new latest.php using the new file you uploaded
I ran 'service httpd restart'
I tested again but got the same old result of a blank page.
Is there another service that needs to be restarted?

Comment by Oleg Egorov (Inactive) [ 2017 Sep 20 ]

Can you show web server (apache) error logs?
In future, you can change php files without restart

Comment by Tim Jahn [ 2017 Sep 20 ]

This is the ssl error log from our front end (/var/log/httpd/)

Comment by Tim Jahn [ 2017 Sep 20 ]

This is the error_log from our front end (/var/log/httpd/).
Perhaps we are having a memory issue?
[Wed Sep 20 08:19:11 2017] [error] [client 173.160.174.153] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 22 bytes) in /var/www/html/zabbix/include/db.inc.php on line 605, referer: https://zabbix.npinfo.com/actionconf.php?ddreset=1

Comment by Tim Jahn [ 2017 Sep 20 ]

Here is the last half hour of the access log (the original file was over 150MB)

Comment by Oleg Egorov (Inactive) [ 2017 Sep 21 ]

Ok, thank you!
There is a problem, memory limit.
Please set more memory_limit in php.ini, for example - 512M.
Now you have 128M.

Then restart web server (service httpd restart)

Comment by Oleg Egorov (Inactive) [ 2017 Sep 21 ]

(2) [F] No translation string changes.

iivs CLOSED

Comment by Tim Jahn [ 2017 Sep 25 ]

I increased the available RAM for the Zabbix Front End from 1GB to 3GB.
I increased php.ini from 128M to 512M.
I restarted the web service.
I still cannot load Monitoring -> latest data.
URL reads as https://zabbix.npinfo.com/latest.php?ddreset=1 and the page is blank.

Comment by Oleg Egorov (Inactive) [ 2017 Sep 25 ]

Now you have frontend limit 512M, not 3 GB if in php.ini memory_limit is 512M.
Can I ask you just, try to set memory_limit 3072M?

Comment by Tim Jahn [ 2017 Sep 25 ]

I checked /var/log/httpd/access_log after first change - no memory errors
I have changed the memory limit to 3072M per your request
I have restarted httpd service
I still get a blank page when visiting monitoring/latest data.

The only issue we ever have with the front end is if a host group gets deleted then anyone that had that as the last location they were viewing will have a broken latest data screen. The latest data screen will be the only broken screen.

Comment by Tim Jahn [ 2017 Sep 25 ]

My mistake, it appears the memory error was from the log /var/log/httpd/error_log
I am still getting errors:
[Mon Sep 25 09:11:36 2017] [warn] RSA server certificate wildcard CommonName (CN) `*.npinfo.com' does NOT match server name!?
[Mon Sep 25 09:11:36 2017] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.4.40 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips configured – resuming normal operations
[Mon Sep 25 09:12:02 2017] [error] [client 173.160.174.153] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 35 bytes) in /var/www/html/zabbix/include/db.inc.php on line 605, referer: https://zabbix.npinfo.com/zabbix.php?action=dashboard.view
[Mon Sep 25 09:17:52 2017] [notice] caught SIGTERM, shutting down
[Mon Sep 25 09:17:52 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)

Comment by Oleg Egorov (Inactive) [ 2017 Sep 26 ]

resuming normal operations
[Mon Sep 25 09:12:02 2017] [error] [client 173.160.174.153] PHP Fatal error: Allowed memory size of 134217728 bytes

134217728 bytes is 128 MB, not 512 MB or 3 GB...

Comment by Oleg Egorov (Inactive) [ 2018 Jan 05 ]

Fixed in:

  • 3.4.6rc1 r76642
  • 4.0.0alpha2 (trunk) r76643
Generated at Fri Mar 29 07:31:54 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.