I have a customer who uses our proprietary software, in the process of debugging the client side software, I discovered the server is not writing to the apache ssl_error_log file (due to nature, server side web app is HTTPS/SSL accessible only and all communications with the client software and the server web application occur over SSL as well).
I've looked over httpd.conf, I've checked php.ini, and still cannot find a reason why it would not be writing.
The file paths are correct, error logging is on in php. No virtual hosts so no separate files to check.
If I stop apache, remove the log files, then restart apache - the log files will be created, but they are never written to. ( - error_log - will contain the apache start up information, but nothing else.) So I would assume it is not a permissions error either.
Whats more perplexing is it was writing fine until June 25, then suddenly all ssl_error_logs just stop. I'm thinking this would point to a logrotate.d error, but I want to be sure of it before touching it. Oddly enough the httpd logrotate work perfectly fine for ssl_access_log & ssl_request_log. They have continued to rotate and create new files daily, and they are recording the data fine.
//Code in logrotate.d file
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
delaycompress
postrotate
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
endscript
}
So what would be the issue with writing to the ssl_error_log, there is obviously an error (we are receiving a 500 error on the client machine's logs from the server).
On another note, we create a test file >
<?php
error_log("Testing Log");
?>
Then we call it from terminal with php /path/testfile.php Neither ssl_error_log, nor error_log will be written (not sure which would when running that at localhost level).
( We know the error is on the client side, but because we cannot determine the nature of the issue at the server side we are stuck debugging it. The issue randomly crops up - may be days,weeks,months - but will eventually happen on 2 of over 50 machines communicating with the server the customer has. We could easily modify the client software to get around the error, or force a restart as this fixes the issue immediately til it appears again, but I'd rather find the actual problem rather than slapping a bandaid on it.)
