guzzlehttp/psr7/src/Util.php
!Friendica Admin Support Group
Okay, after further digging I have excluded any issues with SELinux preventing caching. There have been no SELinux denials at all in the last three days so this issue is going to be in the code base. There are few things in life as enjoyable as hunting down a memory leak. Please note the heavy sarcasm :).
Update:
Okay, The function copyToString() in the Util.php allows the buffer to be read indefinitely or until it reaches an eof(). This only happens if the $maxLen variable is -1, which happens to be its default value. Because we end up in the body of this if() we know that either -1 was passed or the default value was used.
So apparently a file larger than 8gb was served up? That seems extreme though I have raised the bar to 12gb and waiting to see if that fails in time.
This seems reckless as a lot of servers may not have 8gb+ to offer up. This looks dubious and certainly a work around can be reached.
Unus Nemo
in reply to Unus Nemo • • •Rather than continuing to update the post I decided to update via comments.
I increased php memory_limit to 12gb. This has removed the error though I still am seeing issues. After getting some sleep and checking my resources memory usage went up. As I am the only active member this seems unlikely. Though I do have a relay configured so it is not like the instance does nothing while I am not active. Still requires more observation and I am still concerned in regards of a memory leak.
Of course I could put a band-aid on it and just put a cron job to restart the httpd every 6 hours though that should not have to happen. I would rather find the actual issue.
Ken Gahagan
in reply to Unus Nemo • •@Unus Nemo what log are you looking at? Have you enabled specific logging from friendica? I just enabled logging through the admin panel of my deployment so I don't have a great deal of data yet but I currently get nothing back from
find /var/log -type f -exec grep -H guzzlehttp {} \;
(my friendica log - now that it is enabled - is in that tree)
I'll keep looking... Also of note your reference to large files being uploaded and the fact that the image in your post is not displaying. I'll dig in the database to see if I can determine where friendica thinks that image should have landed on my host and see if I can run that question to ground.
Friendica Admin Support Group reshared this.
Unus Nemo
in reply to Ken Gahagan • • •@Ken Gahagan I have my friendica log set to log/friendica.log in friendica's home directory. On my system that is /var/www/html/log/friendica.log.
It was the default and I did not bother to change it. Though I did have to create the log directory and
touch friendica.log
(create an empty log file) and be sure it had the correct file permissions.I have my log settings on warning though If I turn it on to debug it blows my log file up so I have been waiting to deal with the errors and warnings before dealing with the debug issues.
You can also use journalctl to see some errors that are beyond just friendica.
Ken Gahagan likes this.
Unus Nemo
in reply to Ken Gahagan • • •@Ken Gahagan That screenshot was only 519.1kB. It loads on my side though seeing it is saved on my server, that is not surprising. I have posted images to comments before and other users have seen them as they gave me feedback. So I know they are propagating at least in some instances.
Let me know what you find out please.
Ken Gahagan likes this.