Posts made by Daniel Miller

@george1421 This particular machine is only servicing about 30 units with 4 distinct named users and currently reporting about 375MB free. Looking through its history over the past 2 years (reported through snmp), it historically has had anywhere from 350MB to 500MB free, depending on the day of the week. Truncating the userTracking table does make it happy for now. If you are loading that table with PHP on every request, the behavior does make a lot of sense.

@Tom-Elliott I completely understand that, and for this particular environment it is not an important feature. We have some other larger environments (250-ish) where the user tracking feature does get used from time to time (“Hey, was the account of student X used to log in yesterday?”), so It is something I check in my canary system.

@flipwalker The box I have is also Ubuntu 16.04. Check to see if your config file is in /etc/php/7.1/fpm/pool.d/.

Don’t know if this relevant to this issue (if not, let me know and I"ll open another thread), but I’m encountering http 500 responses on the user tracking report page with similar log entries on an ubuntu based system I just upgraded from 1.4.4 to 1.5.2 from a git pull off an existing checkout.

After changing the the pm.max_request setting in /etc/php/7.1/fpm/pool.d/www.conf and changing the memory limit to 2048 (the box only has 2GB), I see a warning about the server reaching the pm.max_children value in /var/log/php7.1-fpm.log followed by a proxy_fcgi:error in /var/log/apache2/error.log citing an out of memory condition in fogcontroller.class.php with referrer /fog/management/index.php?node=report&sub=file&f=dXNlciB0cmFja2luZw==. There is a reference to a line number for the oom error that seems to vary between lines 126 (in __construct()) and 260 (in set()), but I would expect that depends on when it actually ran out. I enabled error reporting in the php settings for apache, but it doesn’t seem to want to get past the 500.

Raising the max_children to 20 shows entries in php7.1-fpm.log about the pool seeming busy and it spawning additional children until the limit is reached then it reports the reaching of the max_children limit again. The proxy_fcgi:error in this case is a timeout dispatching a request to (polling) with the same referrer.

Scaling the memory limit back down to default results in a reference to pdodb.class.php line 602 in the memory exhaustion message.

I also attempted altering the apache configuration, but I only had to add the ProxySet timeout. No change in the error message.

Happy to poke at anything else you might have an idea about. Have a few days before I need to decide to backrev or not.