Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
CentOS 6.5 / PHP 5.3.3 / Observium 0.14.3.5109
Description
When viewing a particular host (but this issue is not exclusive to this host), in most of the cases, the various graphs on the device overview page show "No Auth" in a pink image. When this happens, the session is destroyed and i need to log in again. This doesn't happen all the time, but it does most of the time. See attached image.
There's no indicator that it has to do with the limits specified in php.ini. There's no log entry in the error_log. The session just gets destroyed for no particular reason.
Attachments
Activity
Mike,
I'm attaching a patch to simplify is_graph(). Your original patch probably works for everyone, but I had to rewrite is_graph() because I run Observium in a subdirectory (yes, I know...unsupported config).
Anyway, I'm able to set $lifetime_id = 10 with your changes, and I never see any No Auth images. Looks like the changes resolved the problem.
Mike, looks good (r5326).
I haven't seen a "No auth" graph in the past 30 minutes of continuous paging around, and pages with lots of graphs like the processor health page no longer fail to load some of the graphs.
Mike,
At line 28 of html/includes/authenticate.inc.php, you regenerate the Session ID every 20 seconds ($lifetime_id = 20).
So, let's say you go to a Device Overview page, wait 18 seconds, and then click the Collectd tab (or any page that has many graphs that may take a few seconds to load). Any graphs that are requested after the remaining 2 seconds of our original session will fail with "No Auth" because the browser has already queued up the requests with the original Session ID.
I was able to see this happening in FF with the Network developer tab (F12). Click on a GET request and then the Cookies tab to watch the cookies change.
I ended up setting $lifetime_id = 43200 (12 hrs) since I figured my session could expire when I'm out of the office. Adam thought you may want to avoid generating new Session IDs when hitting graph.php, but I'll leave that to you guys.
Hi Mike,
I just upgraded to latest (5277) and will keep an eye open for this issue. Please keep the ticket open for a few more days.
Thanks!
Remco, you are here? 
Please check if after r5275 problem solved for you.
Hi guys. I might have some useful input for you.
I suffered the same problem for a longer time (session kick out when I clicked on an as9k or cat4k5 and the auth failure graphs). I regulary updated but the problem with "auth failure" did not go away. The session kickout was getting more sporadig and I could get rid of it with the workaround via "Rememeber my login" when authenitcating. The auth failure graph were gone after I dramatically reduced the number of polled ports, I acutally run into another problem (http://www.observium.org/wiki/FAQ#When_submitting_large_forms_such_as_port_ignore.2Fdisable_settings.2C_not_all_my_settings_are_saved._How_come.3F) were I was unable to disable polling.
Finally after I could disable polling for the most ports, the auth failure problem was going away. I disable more and more ports (our Cat4k5 have 1233 ports available!) and the problem soon was gone. I did not have this problem on our other Observium inststance because there we only use "normal" switchtes with 24 ord 48 ports and not more. On our affected installation we have mainly 4x ASR9K and 7x Cat4507.
Btw: I did not disable the xchace as described.
BR,
Marco
I disabled xcache, using your instructions for debian. here is the current output of "php -i | grep -i cache", which seems to confirm that it has been disabled.
realpath_cache_size => 16K => 16K
|
realpath_cache_ttl => 120 => 120
|
user_ini.cache_ttl => 300 => 300
|
phar.cache_list => no value => no value
|
session.cache_expire => 180 => 180
|
session.cache_limiter => nocache => nocache
|
soap.wsdl_cache => 1 => 1
|
soap.wsdl_cache_dir => /tmp => /tmp
|
soap.wsdl_cache_enabled => 1 => 1
|
soap.wsdl_cache_limit => 5 => 5
|
soap.wsdl_cache_ttl => 86400 => 86400
|
oh dear, yes i believe I did. Sorry about that.