VMware Cloud Community
kavips
Contributor
Contributor
Jump to solution

/Storage/Log is full due to content-library-runtime.log.stdout

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!

Reply
0 Kudos
1 Solution

Accepted Solutions
Mike_P
Enthusiast
Enthusiast
Jump to solution

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.

View solution in original post

Reply
0 Kudos
15 Replies
ptarnawski
Hot Shot
Hot Shot
Jump to solution

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
Tags (1)
Reply
0 Kudos
kavips
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
ptarnawski
Hot Shot
Hot Shot
Jump to solution

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-231883113318831049
vCenter Appliance 6.7 Update 3o (6.7.0.50000)2021-09-211848516618485185

 

 

Or just go for the newest one: 

vCenter Appliance 6.7 Update 3r (6.7.0.53000)2022-07-121983297419832280





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
Reply
0 Kudos
kavips
Contributor
Contributor
Jump to solution

Unfortunately, that doesn't appear to be the case as we've already been on the latest build for a couple weeks.

Reply
0 Kudos
navina
Enthusiast
Enthusiast
Jump to solution

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

Regards,
Navin A
Reply
0 Kudos
ptarnawski
Hot Shot
Hot Shot
Jump to solution

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
Reply
0 Kudos
kavips
Contributor
Contributor
Jump to solution

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%. 

Reply
0 Kudos
Mike_P
Enthusiast
Enthusiast
Jump to solution

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.

Reply
0 Kudos
kavips
Contributor
Contributor
Jump to solution

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!

Reply
0 Kudos
Auxiliary-Team
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
RajeevVCP4
Expert
Expert
Jump to solution

https://kb.vmware.com/s/article/89009

Rajeev Chauhan
VCIX-DCV6.5/VSAN/VXRAIL
Please mark help full or correct if my answer is use full for you
Reply
0 Kudos
Auxiliary-Team
Contributor
Contributor
Jump to solution

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.

Reply
0 Kudos
Ajay1988
Expert
Expert
Jump to solution

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

If you think your queries have been answered
Mark this response as "Correct" or "Helpful".

Regards,
AJ
Auxiliary-Team
Contributor
Contributor
Jump to solution

@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

Reply
0 Kudos
domidesb
Contributor
Contributor
Jump to solution

Hi

I went thought the exact same issue and I fixed it by following this kb:

https://kb.vmware.com/s/article/89009

Thanks

 

 

Reply
0 Kudos