New to VMware Communities and not sure if this is the appropriate spot to post this or not, but I'm hoping someone can help me out. Our disk space on the /log partition is almost full and it seems to be due to the "content-library-runtime.log.stdout" file. Now, I did find and follow the steps at the appropriate KB Article but it doesn't look like the data is shrinking at all.
Has anyone else had this issue and followed the steps at the KB? If so, did you notice an immediate improvement or did it take some time?
Thanks in advance!
Have you truncated the offending log file (/storage/log/vmware/content-library/content-library-runtime.log.stdout)? The fix stops the logging of all the debug messages to this file that cause it to grow huge, but unless restarting the service truncates the log you will need to do that manually or you won't reclaim the space used.
It states in the KB that the issue was fixed in 6.7 P08.
Suggesting you upgrade to a fixed version.
Thanks for the reply!
I saw that too, but it doesn't appear that 6.7 P08 is available yet, so I was hoping to find a fix until its release.
What I think there is an error ok KB and version should be:
vCenter Appliance 6.7 Update 3p (6.7.0.51000) | 2021-11-23 | 18831133 | 18831049 |
vCenter Appliance 6.7 Update 3o (6.7.0.50000) | 2021-09-21 | 18485166 | 18485185 |
Or just go for the newest one:
vCenter Appliance 6.7 Update 3r (6.7.0.53000) | 2022-07-12 | 19832974 | 19832280 |
Unfortunately, that doesn't appear to be the case as we've already been on the latest build for a couple weeks.
6.7P08 is not yet released!
The KB also says the issue is seen only after updating to 6.7U3r(The latest release)
Request you to follow the workaround mentioned in https://kb.vmware.com/s/article/89009
Hey @navina
The user said he followed workaround already
Hi @navina
Thank you for your response. As @ptarnawski mentioned, I already tried the workaround before I made my initial post. In fact, I just double checked the contents of the log4j.properties file and its ownership and everything appears to be matching what the workaround recommends, but the size of the /log/ partition is still over 90%.
Have you truncated the offending log file (/storage/log/vmware/content-library/content-library-runtime.log.stdout)? The fix stops the logging of all the debug messages to this file that cause it to grow huge, but unless restarting the service truncates the log you will need to do that manually or you won't reclaim the space used.
Thanks for the suggestion. I actually ended up looking into the log files as well as the "fixed" log4j.properties code a bit more yesterday and did exactly that once I realized that's what happened. It's now down to about 35% and doesn't seem to be ballooning anymore so I think we're good.
Thanks for the help, everyone!
When you say "Have you truncated the offending log file (/storage/log/vmware/content-library/content-library-runtime.log.stdout", what's the best practice to truncate this file?
I have gone through the work around and there's still a *.log-1.stdout file that's 5.6 GB in size.
https://kb.vmware.com/s/article/89009
Thank you, i went through this procedure yesterday, however the 5.6 GB stdout log file still exists. I'm looking for a best practice on how to clear this log file. Unclear if the file will regenerate if manually deleted. This is why I'm asking what the best practice is to 'Truncate' these log files.
Thanks in advance.
Please truncate/zero out the file as I do not think the file size will come down. The workaround will stop it from increasing further only .
cat /dev/null > content-library-runtime.log.stdout
@Ajay1988Thank you, I was not aware of the command 'cat /dev/null > content-library.log-1.stdout' which did truncate\zero out the file resulting in freeing up 5.6 GB.
Thank you - B
Hi
I went thought the exact same issue and I fixed it by following this kb:
https://kb.vmware.com/s/article/89009
Thanks