FOG User Tracking -Search

[Daniel Miller]

That log file may be /var/log/php7.1-fpm.log on Debian / Ubuntu

[Greg Plamondon]

@Daniel-Miller
Sorry, I should know better.
Centos 7.7
Fog Version: 1.5.7.56
approximately 400 users give or take.

[Greg Plamondon]

@Tom-Elliott said in FOG User Tracking -Search:

/var/log/php-fpm/www-error.log

[06-Dec-2019 14:21:28 UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 8192 bytes) in /var/www/html/fog/lib/db/pdodb.class.php on line 622

Thanks.

[Tom Elliott]

@Greg-Plamondon If you update FOG Settings -> General -> Memory Limit to 512, does this help fix the issue you’re seeing?

For what it’s worth, while not 100% ready for prime time, I believe this should be addressed better in 1.6 (if you can create a test environment and test this, it may work a little better, though the reporting for these things have changed quite a lot.)

[Greg Plamondon]

@Tom-Elliott I changed it to 512, but my php.ini is set to 1024.

[Tom Elliott]

@Greg-Plamondon Then you can set the memory_limit to 1024 as well.

The ini is for initialization of PHP itself. FOG uses the database value for most things contained within. I’m going to guess that your original memory limit was set at 256 right?

[Greg Plamondon]

@Tom-Elliott said in FOG User Tracking -Search:

256

in the GUI it was set to 128, I changed it to 1024 and I still get the HTTP error 500 and same log message.
I even restarted httpd.

[Daniel Miller]

@Greg-Plamondon did you restart the fpm service? Command to do so will be similar to sudo systemctl restart php7.1-fpm.service.

[Daniel Miller]

Actually, if the allocated memory size in the exhaustion messages is remaining constant at 268435456 across all changes and you have yet to see anything referencing a memory size of 256MB, it might be time to go digging for where that value is set. It may be worth running a sudo grep -r memory_limit /etc/* to see in which ini that 256M is set and modify the value there. If it is in the fpm php.ini, you will need to restart the php fpm service.

[Greg Plamondon]

@Daniel-Miller said in FOG User Tracking -Search:

grep -r memory_limit /etc/*

grep -r memory_limit /etc/*
/etc/php-fpm.d/www.conf:php_admin_value[memory_limit] = 256M
/etc/php.ini:memory_limit = 1024

changed: /etc/php-fpm.d/www.conf:php_admin_value[memory_limit] = 1024M
and restarted FPM service.
now get this message in the log.

[06-Dec-2019 17:02:32 UTC] PHP Fatal error:  Allowed memory size of 1073741824 bytes exhausted (tried to allocate 12288 bytes) in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 260

Thanks.

[Greg Plamondon]

@Daniel-Miller said in FOG User Tracking -Search:

@Greg-Plamondon did you restart the fpm service? Command to do so will be similar to sudo systemctl restart php7.1-fpm.service.

yes: systemctl restart php-fpm

[Greg Plamondon]

the VM has 16G of RAM,
I changed /etc/php-fpm.d/www.conf:php_admin_value[memory_limit] = 8192
to see if that would help, but now i get this and nothing in the /var/log/php-fpm/www-error.log

the /var/www/httpd/error_log:

[Fri Dec 06 12:14:10.523177 2019] [proxy_fcgi:error] [pid 5254] (70007)The timeout specified has expired: [client 192.168.10.170:55422] AH01075: Error dispatching request to :, referer: http://10fogserver.mtstrans.com/fog/management/index.php?node=report&sub=file&f=dXNlciB0cmFja2luZw==```

[Daniel Miller]

Good, the values are changing.

there is also an execution time limit that should be set in one of the ini / conf files as well. I believe the setting is max_execution_time which I think takes a value in seconds and defaults to 30. you may want to play with that value to see if you can get a response in a reasonable time. It may take upwards of a minute or two depending on how many entries are getting pulled.

[Greg Plamondon]

This post is deleted!

[Greg Plamondon]

@Daniel-Miller said in FOG User Tracking -Search:

Good, the values are changing.

there is also an execution time limit that should be set in one of the ini / conf files as well. I believe the setting is max_execution_time which I think takes a value in seconds and defaults to 30. you may want to play with that value to see if you can get a response in a reasonable time. It may take upwards of a minute or two depending on how many entries are getting pulled.

So far I have changed the /etc/php.ini max_execution_time = 300 with no luck.

[Fri Dec 06 14:20:04.488209 2019] [proxy_fcgi:error] [pid 2045] (70007)The timeout specified has expired: [client 192.168.10.170:63425] AH01075: Error dispatching request to :, referer: http://10fogserver.mtstrans.com/fog/management/index.php?node=report&sub=file&f=dXNlciB0cmFja2luZw==```

[Greg Plamondon]

@Daniel-Miller said in FOG User Tracking -Search:

Good, the values are changing.

It may take upwards of a minute or two depending on how many entries are getting pulled.

I checked the userTracking table in the fog database and it has 22104 records
By the way, this hasn’t worked for us for quite some time, I just never got around to reporting it.
but now I have been getting a lot of requests for reports and it was nice to be able to quickly generate what time a user logged into the pc.

[Daniel Miller]

@Greg-Plamondon said in FOG User Tracking -Search:

I checked the userTracking table in the fog database and it has 22104 records

You can keep pushing execution time out, but it is quite possible that you may have too many entries for php to handle the data in a reasonable time frame, especially if this instance has been running for a while. If you don’t need the historical data, truncating the userTracking table (truncate table fog.usertracking) as suggested in https://forums.fogproject.org/topic/11713/503-service-unavailable-error/54 should get it up and running and will show data going forward until it gets too ungainly again.

[Greg Plamondon]

@Daniel-Miller said in FOG User Tracking -Search:

@Greg-Plamondon said in FOG User Tracking -Search:

I checked the userTracking table in the fog database and it has 22104 records

You can keep pushing execution time out, but it is quite possible that you may have too many entries for php to handle the data in a reasonable time frame, especially if this instance has been running for a while. If you don’t need the historical data, truncating the userTracking table (truncate table fog.usertracking) as suggested in https://forums.fogproject.org/topic/11713/503-service-unavailable-error/54 should get it up and running and will show data going forward until it gets too ungainly again.

I was able to truncate the table and then run a report. I wish i was able to store more records.

[Tom Elliott]

While I have no grounds to substantiate the claim, I really believe 1.6 will handle this kind of thing much better. Sure I don’t have 22k worth of entries (or more depending on the use case) in my userTracking table, but now that we have pagination, things should be a little better here. This, of course, makes reporting for “all” of the rows a little more difficult. But at least it allows searching and viewing information a little simpler without having to go to the extreme of truncating the whole table.

I’m sorry it took so long for us to have this implemented.

[Greg Plamondon]

@Tom-Elliott said in FOG User Tracking -Search:

1.6

I have ## Version: 1.5.7.56 installed…
what repo is 1.6 in?