Problem:
foreman-proxy keeps file descriptors of delete log files in /var/log/foreman-proxy/ . It consumes ~ 1GB per hour until disk is full. Foreman-proxy process probably creates file proxy.log.1, then gzips the file and deletes the original file BUT FD keeps open and consumes disk space
This behavior occurs randomly Foreman and Proxy versions:
1.20.2
I donāt have a system at hand, but whatās in the logrotate config? Normally it should run systemctl kill --signal=SIGUSR1 --kill-who=main foreman-proxy to notify foreman-proxy to open the new file. Can you verify that actually opens new files? If it doesnāt, then we know the bug is in the proxy. Otherwise itās in the delivery.
It sounds like the proxy never switched to the new file which meant it stayed empty which meant it was never rotated again. Itās hard to say why this happened because itās hard to reproduce.
These files have constant size and do not grow.
I have checked monitoring for historical data of disk usage and this issue happend probably on 17.4.,25.4.,10.5.,13.5.,28.5.,13.6.,20.6.,3.7. - so there is no regular occurence.
All components from Foreman and even Katello can be configured for syslog logging and we could easily get rid of this rotating madness completely if we were able to configure rsyslog/syslogng to deliver messages to the same filename. But thanks to Puppet, this requires huge amount of work and another two components to manage which @ekohl is not happy with. I wish there was an easy way to solve this, syslog/journald is much more powerful.
You can however tell the installer to configure syslog or even journald and then configure log file destinations yourself easily. All bits are here: https://github.com/lzap/foreman-elasticsearch (just skip the ES steps).
there are still FD of deleted files - each day one more. I restart the foreman proxy at least once a week so the issue with no space left on hdd hasnāt occured yet.
@ivos multiple other customers are running into the issue, I am wondering if you can do the final confirmation that the patch works as expected. thanks!
Hi Lukas,
I have just checked the monitoring tool for disk free statistics and there wasnāt any issue since the patch had been applied. It wasnāt also necessary to restart the foreman-proxy service. For me, the problem is solved. Thanks.
Ivos
After reviewing our code, logging gem and logrotate configuration, I came to conclusion that logrotating proxy is not configured properly. Our proxy is configured by default to do rotation on its own on a weekly basis. Although our puppet configuration comment says it is also maxed out at 100MB, in the code I see we do not enforce this (size is set to zero). Number of logs to keep is at 6. Here is a config snippet:
Now, in the codebase logging stack use rolling mechanism only and only if size > 0. Therefore, unless the size configuration value is uncommented, no rolling is performed in the proxy. A bit confusing, but so far so good.
This is normal daily rotation with compression, which is I believe simple file rename operation. Then USR1 signal is used to reopen log files. Here, I am a bit fuzzy finding out why proxy or logger rubygem would open rotated file since rotation within proxy is turned off (by default)
Anyway, to solve this, I think we need to do copytruncate here just like we do with Ruby on Rails.