- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It states in the KB that the issue was fixed in 6.7 P08.
Suggesting you upgrade to a fixed version.
Visit my blog:AngrySysOps.com
YT: AngryAdminYoutube
Visit my:Xwitter
If my answer has successfully addressed your issue, kindly mark it as RESOLVED. If it has provided valuable assistance, consider giving it a KUDOS. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 |
Visit my blog:AngrySysOps.com
YT: AngryAdminYoutube
Visit my:Xwitter
If my answer has successfully addressed your issue, kindly mark it as RESOLVED. If it has provided valuable assistance, consider giving it a KUDOS. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, that doesn't appear to be the case as we've already been on the latest build for a couple weeks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Navin A
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey @navina
The user said he followed workaround already
Visit my blog:AngrySysOps.com
YT: AngryAdminYoutube
Visit my:Xwitter
If my answer has successfully addressed your issue, kindly mark it as RESOLVED. If it has provided valuable assistance, consider giving it a KUDOS. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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%.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
https://kb.vmware.com/s/article/89009
VCIX-DCV6.5/VSAN/VXRAIL
Please mark help full or correct if my answer is use full for you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Mark this response as "Correct" or "Helpful".
Regards,
AJ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I went thought the exact same issue and I fixed it by following this kb:
https://kb.vmware.com/s/article/89009
Thanks