Updated from .32 to 1.1.0 to 1.1.2 to 1.2.0 - User Login Hist page blank
-
Apologies if I was supposed to put this in a bug report in another section.
-
[quote=“UpACreek, post: 38530, member: 24526”]Apologies if I was supposed to put this in a bug report in another section. :([/quote]
you didn’t do anything wrong, if anything i did. you posted about this problem originally around the time when the reports system was being reworked, and i just assumed this issue had been resolved. this issue only seems to pop up on systems with a large amount of data in the userTracking table, which doesn’t tend to happen on dev boxes. since i’ve never really ran those reports on my production server, and they worked fine on my dev server, i assumed all was well.
-
Thank you for the info.
I’m running Ubuntu 12.04 with 2gb of RAM. I switched the memory amount from 128mb to 1024mb, and attempted the report again. This time, it acted like it was going to do the report, as it sat there processing the request for close to 10 seconds, but then ultimately displayed a blank page.
I’ve got 466 hosts on this box, that track over 500 users on a daily basis. I’m guessing my login report is huge…
-
I’ve manually tried purging old entries too trying to make the result return fast, but no luck. I’m at 1600+ hosts and and 3600+ users that could be in and out many times a day. I don’t recall having any problems until after the upgrade to 1.2. But I can’t say for sure we would have used the report from 1.0 on. That development was pretty fast and mostly installed over the summer when teachers and students are not around.
-
I would suggest you change your memory to 256mb should accelerate the page load and still accommodate your history file. I have 736 machines with 984 users. My report works fine with 256M.
-
Just utilized the database backup option located under Fog Configuration > Configuration Save and it dropped a 43mb sql file. Login records span from 2012 to now, and there are ~614,000 records just in the login history table.
-
[quote=“Wolfbane8653, post: 38547, member: 3362”]I would suggest you change your memory to 256mb should accelerate the page load and still accommodate your history file. I have 736 machines with 984 users. My report works fine with 256M.[/quote]
I upped mine to 1536M just to see. I still could not get my login history to load.
-
Just for clairification this is the file you changed right?
/etc/php5/apache2/php.ini
changed memory_limit = 256M
the restarted apache
RIGHT? -
Well I doubt it will fix the problem would you be willing to try persistent database connection rather than just create a new thread and connect to the database
-
If that is the only thing I should be modifying… yep. Just tried 256M for the fun of it. No dice.
[ATTACH=full]1470[/ATTACH]
[url=“/_imported_xf_attachments/1/1470_phpini.png?:”]phpini.png[/url]
-
[quote=“Tom Elliott, post: 38553, member: 7271”]Well I doubt it will fix the problem would you be willing to try persistent database connection rather than just create a new thread and connect to the database[/quote]
I’m willing to try anything, just let me know what I have to do.
-
The file /var/www/fog/lib/fog/Conffig.class.php
Change the database_host field so it states p:ip.of.fog.srv if it’s the local host try p:127.0.0.1
-
Current entry is:
define(‘DATABASE_HOST’, ‘localhost’);Changing to:
define(‘DATABASE_HOST’, ‘p:127.0.0.1’);Restarting FOG server…
No dice. Blank page…
-
[quote=“UpACreek, post: 38550, member: 24526”]I upped mine to 1536M just to see. I still could not get my login history to load. :([/quote]
I’ve tried the same. I run fog in a ESXi VM. It used to run on a total of 512mb ram and 1 cpu just fine, but trying to resolve this I’ve increased to 2gb ram and Dual CPU. I have 1.72 million records in my user tracking table, going back to the 12-31-2013. I used to have record back to 2011 I think but I purged those out, at least 4 million or so that I deleted.
Looking at the table I wonder if there is a way to ignore a user from the logs. We have a few automatic logon labs that restart frequently. I would like to keep tracking enabled on the machine to log any bypasses of the autologon, but for now I’m disabling tracking on those computers.
-
I’m taking a quick look at the way php and mysql is handled. It shouldn’t be a problem no matter the number of results, but php defaults to a buffered set which should only be used in a case were we must know the number of results or we know it’s going to be limited, unbuffered should allow much large return sets. I’m testing.
-
I’m game to try other ideas. Just let me know. We’re fumbling around quite a bit without this report. You don’t realize how important a feature is, until it suddenly isn’t available.
-
Take a look at the current svn.
You can update your memory_limit right in fog gui.
I’m also taking an approach to use MYSQLI_USE_RESULT for the results page to allow, hopefully, a better size in the variable that’s stored, though it’s not likely to fix all issues.
That said, you no longer need to, nor will it affect fog anymore, set the memory_limit in the php.ini file as it’s set in FOG and uses that value specifically. It defaults to 128 and will never go lower than that. Nice part is you don’t need to restart apache either for the changes to take effect.
-
I’ll give it a go. crosses fingers I’ll let you know.
-
Bummer… still a blank page after going to Login History.
Even tried changing the memory in the GUI to 1024, but still no dice. -
How large is your userTracking Table in mysql?
