Updated from .32 to 1.1.0 to 1.1.2 to 1.2.0 - User Login Hist page blank
-
Update on this: I increased the php memory limit in php.ini from 128M to 1024M and the login history is working now. The only reason I haven’t tried this before is because I’ve never seen a need to do this in other applications. My fog userTracking table currently has ~25,000 rows. I have other applications with millions of rows in a table that still work fine on 128M of memory.
-
Hi. I was having the same problem with FOG v1.2.0 on Ubuntu 14.04.1 … my user tracking was not working. I also changed “memory_limit=128M” to “memory_limit=1024M” in the /etc/php5/apache2/php.ini file that that fixed the problem - I can now view the user tracking information from the management website.
-
[quote=“Junkhacker, post: 34643, member: 21583”]that file should not be there. that report is handled by a class file now
i think you’ve identified a bug. it should be fixed soon[/quote]Any update on this? Version 1.2 released before this issue and is still current . We used to frequently use this report and are now stuck with less reliable methods.
-
[quote=“John Sartoris, post: 38526, member: 24837”]Any update on this? Version 1.2 released before this issue and is still current . We used to frequently use this report and are now stuck with less reliable methods.[/quote]
Somehow I missed that there were previous replies. I have not received any information on a fix, but am tempted to pursue the memory issue just to see if that does anything. I’ll see what happens…
-
i didn’t realize this was still an issue, thank you for the bug report
-
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.
