10-10-2018 12:31 PM
So, my OpsCenter server crashed today ( I just updated to 8.1.2 ) and it was due to the C: drive filling up!
Bunches of java## files in C:\Windows\System32\config\systemprofile - if you use OpsCenter check it out. Apparently at earlier versions there was a bug that created tonnes of these and left them there - I had ones from 2006 - 2016.
1. Letting you know you may want to clean these up, apparently you can delete the old ones without issues.
2. Found these two solved links:
https://vox.veritas.com/t5/OpsCenter/OpsCenter-Java-Logging-to-systemprofile/m-p/758765
Neither one clearly resolves how to manage these files - so that is my question
3. Is there anywhere I can configure to max these out either by number of files or size to prevent them from filling my C: drive again?
Solved! Go to Solution.
10-10-2018 01:08 PM
Found this gem: https://www.veritas.com/support/en_US/article.100044146.html
Problem
After install or upgrade of OpsCenter to version 8.1.2 on Linux or Windows, the java0.log file continues to grow in size until it fills up the file system.
The location of the java0.log file:
Linux: /root/java0.log
Windows: C:\Windows\System32\config\systemprofile\java0.log
Solution
1.) Edit the log.conf file, adding the following lines: 148.LogManagerResetFlag=true 147.LogManagerResetFlag=true The location of the log.conf file: Linux: /opt/SYMCOpsCenterServer/config/log.conf Windows: <install_path>\OpsCenter\server\config\log.conf 2.) Then the OpsCenter services need to be restarted to read in the changes. The services can be bounced by using the following commands: Linux: /opt/SYMCOpsCenterServer/bin/opsadmin.sh stop /opt/SYMCOpsCenterServer/bin/opsadmin.sh start Windows: <install_path>\OpsCenter\server\bin\opsadmin.bat stop <install_path>\OpsCenter\server\bin\opsadmin.bat start
10-10-2018 01:08 PM
Found this gem: https://www.veritas.com/support/en_US/article.100044146.html
Problem
After install or upgrade of OpsCenter to version 8.1.2 on Linux or Windows, the java0.log file continues to grow in size until it fills up the file system.
The location of the java0.log file:
Linux: /root/java0.log
Windows: C:\Windows\System32\config\systemprofile\java0.log
Solution
1.) Edit the log.conf file, adding the following lines: 148.LogManagerResetFlag=true 147.LogManagerResetFlag=true The location of the log.conf file: Linux: /opt/SYMCOpsCenterServer/config/log.conf Windows: <install_path>\OpsCenter\server\config\log.conf 2.) Then the OpsCenter services need to be restarted to read in the changes. The services can be bounced by using the following commands: Linux: /opt/SYMCOpsCenterServer/bin/opsadmin.sh stop /opt/SYMCOpsCenterServer/bin/opsadmin.sh start Windows: <install_path>\OpsCenter\server\bin\opsadmin.bat stop <install_path>\OpsCenter\server\bin\opsadmin.bat start
10-11-2018 05:04 AM - edited 10-11-2018 05:05 AM
Thanks for brining that up ...
I recovered 41GB by doing so and was close to fill up system drive!!
======EDIT=====
What a shame I can't click KUDO on this ... most likely due to subject being solved....
10-25-2019 03:08 PM
Hi,
Can you please let me know what exactly editing the log file as "LogManagerResetFlag=true" does? What is its functionality?
148.LogManagerResetFlag=true 147.LogManagerResetFlag=true
10-28-2019 04:20 AM - edited 10-29-2019 12:50 PM
LOL - you will need to ask veritas - it is their solution...
https://www.veritas.com/support/en_US/article.100044146.html
Blind leading the blind anyone?
I did go back and verify my own sample, just one file
java0 with 1KB
<?xml version="1.0" encoding="windows-1252" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
</log>
02-14-2020 08:45 AM