cancel
Showing results for 
Search instead for 
Did you mean: 

OpsCenter systemprofile java# files - management, cleanup, etc

Genericus
Moderator
Moderator
   VIP   

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/What-are-System32-config-systemprofile-javaXX-log-files-in/m-p/...

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?

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS
1 ACCEPTED SOLUTION

Accepted Solutions

Genericus
Moderator
Moderator
   VIP   

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

 

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

View solution in original post

5 REPLIES 5

Genericus
Moderator
Moderator
   VIP   

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

 

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

quebek
Moderator
Moderator
   VIP    Certified

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

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

 

Genericus
Moderator
Moderator
   VIP   

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>

 

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS

Genericus
Moderator
Moderator
   VIP   

Still happening in 8.2

NetBackup 9.1.0.1 on Solaris 11, writing to Data Domain 9800 7.7.4.0
duplicating via SLP to LTO5 & LTO8 in SL8500 via ACSLS