Updated from .32 to 1.1.0 to 1.1.2 to 1.2.0 - User Login Hist page blank
-
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 -
Thank you for the information. I look forward to the upcoming updates.
-
Hi, just wondering what the status is of this issue? I have the same problem but I see a different error in the apache log:
[Tue Aug 12 08:23:04 2014] [error] [client 10.162.3.26] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 83 bytes) in /var/www/fog/lib/fog/Host.class.php on line 308
My /var/www/fog/management/reports folder only has the “Hosts and Users.php” file
Thanks!
-
Any updates on this? School is back in session and we would like to view history…
-
what distros of linux do you have fog installed on?
-
I’m on Ubuntu 12.04
-
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
