I'm dealing with a problem where Solr 5.1 is creating way too many log files. Every time Solr is restarted, and periodically throughout the week, Solr creates the following files and I need it to stop:
Files of the type solr_gc_xxxxxxxx_xxxx, where the x's stand for the date and some kind of identifying number, respectively. These contain garbage collection information.
Files of the type solr_log_xxxxxxxx_xxxx, where the x's stand for the date and some kind of identifying number, respectively. These contain the same kind of information you'd find in solr.log.
One file of the type solr-[port]-console.log. It always contains
only the following text: WARNING: System properties and/or JVM args
set. Consider using --dry-run or --exec
In one week I racked up nearly thirty of files of the type 1 and 2!
Even worse, file types 1 and 2 don't seem to respect my log4j.rootlogger setting and instead are filled with INFO level material.
Here are the relevant parts of my log4j.properties file:
# Logging level
solr.log=logs
log4j.rootLogger=WARN, file
#- size rotation with log cleanup.
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.MaxFileSize=100MB
log4j.appender.file.File=${solr.log}/solr.log
log4j.appender.file.MaxBackupIndex=0
What I want to do is the following:
Create only solr.log + one backup file. solr.log should be periodically overwritten.
Not create any other log file.
What can I do to accomplish this?
So after some time, I figured out how to fix this.
To recap, Solr kept creating a whole bunch of files with the solr_log* and gc_log* patterns on startup and periodically throughout the day. Eventually I had some pretty serious space issues because of the endless amount of logs Solr likes to create.
Navigate to /path/to/solr/bin and locate the solr script, which runs at startup. Open the file, look for the following, and comment out mv "$SOLR_LOGS_DIR/solr.log" "$SOLR_LOGS_DIR/solr_log_$(date +"%Y%m%d_%H%M")":
# backup the log files before starting
if [ -f "$SOLR_LOGS_DIR/solr.log" ]; then
if $verbose ; then
echo "Backing up $SOLR_LOGS_DIR/solr.log"
fi
mv "$SOLR_LOGS_DIR/solr.log" "$SOLR_LOGS_DIR/solr_log_$(date +"%Y%m%d_%H%M")"
fi
Or remove it, if you like. You could also try not using the -f flag but here at my shop we like it.
This will retain solr.log, but Solr won't make any more backups. If you want daily backups, I recommend configuring a TimeBasedRollingPolicy or, better yet, a DailyRollingFileAppender in the log4j.properties file, which can be found under /path/to/solr/server/resources.
If you want, you can also comment out the mv line for the Solr garbage collection logs, which will leave you with solr_gc.log only.
If, like me, you have other ways you monitor gc for Solr, then you need to turn off gc logging completely.
In the same directory as the solr script, open solr.in.sh (Mac/Linux only, I think solr.cmd is for Windows users) and comment this line out: # Enable verbose GC logging
GC_LOG_OPTS="-verbose:gc -XX:+PrintHeapAtGC -XX:+PrintGCDetails \
-XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime".
You will need to restart Solr.
Related
As shown in the figure above; Every time you operate git command, some warning messages will appear.
I found some answers on the Internet;
For example, the following：
Only valid for git GUI; When I close the GIT GUI and reopen it, the warning message still exists;
I tried another way:I modified a configuration file in the GIT installation directory
I added a line of code: unset GIT_ TRACE_ PACKET GIT_ TRACE.
In this way, there will be no warning message through git GUI operation; However, when I operate through the console of idea, the warning message still exists and cannot be eliminated; May I ask you guys how to solve this problem?
This has nothing at all to do with java.
You get this message because you have GIT_TRACE set in your environment, to a value that Git does not understand. Your scripts as written cannot change your shell's setting. See environment-variables, and, e.g., Best way to set environment variables in calling shell and Can a shell script set environment variables of the calling shell?.
To unset GIT_TRACE in your current shell, run unset GIT_TRACE. To set it to a different variable, run export GIT_TRACE=value. The set of valid value-s includes 0 (off—this has the same effect as un-setting the variable), 1 and 2 (on and trace goes to stderr), higher numeric values (trace goes to an already-open file descriptor), and path names starting with /.
Any new shells you create may get GIT_TRACE set based on dot-files (e.g., .bashrc) or other startup items you have chosen. To change this, find your startup items and modify them. If your GUI creates a new shell every time you ask it to do anything, you will have to use this method.
I'm using Tomcat9 as a server and I'm using Catalina.out as my logger output "System.out" and "System.error" . I don't know every time I open and refresh the Catalina.out file, it gives out the weird output (as shown in picture below) and this output is keep increasing until more than million length. It makes slow loading to open the Catalina.out file. After this weird thing loaded, the logger output that I needed will be at the bottom of those things.
Opened Catalina.out via notepad++ will have below output :
I expect the output doesn't give this weird annoying output.
Guess you need some formatting here. Just follow these steps.
Open your file in Notepad++
Type Control-A (select all)
Type Control-H (replace) In 'Find What' type '\x00'
In 'Replace With' leave BLANK In 'Search Mode' Selected 'Extended'
Then Click on 'Replace All'
I think, the encoding of the log is wrong.
May be, you should check the property of the log writing of Apache Tomcat.
(see http://tomcat.apache.org/tomcat-9.0-doc/logging.html)
Hope, it should help you.
I just found out that weird output will only happens when I delete all the Startup logger in Catalina.out.
Example of Startup logger :
.
.
{some logger}
08-Aug-2019 15:15:22.692 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [33,192] milliseconds
If I just leave it, it will not give the weird output again.
So, I will close this issue.
I have following configuration for my service
exec java -Djava.io.tmpdir=$tmpdir -Djava.library.path="Some_Path"
-Xmx"$heapsize"m -XX:+UseConcMarkSweepGC -XX:OnOutOfMemoryError="Do something, may be restart"
-XX:ErrorFile=/var/log/service/myService/"myServiceCrash".log -jar .jar
I am not able to append the crash logs into the same file. But new file with new PID is created every time.
Requirement : Dump crash logs into same file.
This is expected behavior. For the first time it will write to the file provided in -XX:ErrorFile=, Once the file exists it won't be overwritten and you will then get the default error file.
Ideally there should be some way top show the file creation fails, but it can't be done as part of the error handling code.
Please check the evaluation here - https://bugs.openjdk.java.net/browse/JDK-8189672
I'm trying to profile my application to see if I can reproduce this blogpost. I added -D mapred.task.profile=true to the command line and checked in the job configuration that it took.
Hadoop: The Definitive Guide says the profile info will appear in the Unix dir I ran the job from. The dir I started from has a file attempt_201305011806_0042_m_000002_0.profile, which is correct job ID but there wasn't a mapper #2 (only 1 mapper and it didn't fail). The output only has the header info in the profile file; there isn't any actual profiling info.
The Hadoop docs say the output will be in the user log directory but I can't find anything. If I go into the task logs for the mapper, there's profiling info under "profile.out logs" with legitimate info. My HDFS output dir doesn't have the profiling info at all. Shouldn't the profiling output be in HDFS somewhere?
Also, it only gives text-based output in the log but all of the tools I've found to visualize the profile assume binary hprof format. Any ideas for how I could get a binary profile or else load a text-based profile into an hprof tool?
I noticed there's a space at
-D mapred.task.profile=true
Is that a typo? If yes, just remove it and see what happens. Also, you should be able to see a profiler files under the user log directory, which is usually where you ran the job from.
Also, hprof is the default for hadoop, so check if you are not overwriting it with
-Dmapred.task.profile.params
I'm using java system logging in tomcat 7, but no logging statements get written to the log. I've added this file to my WEB-INF/classes. The log file "new-xyz-test" gets created (so I have at least some of the config right) but its empty - no log statements get printed to it.
handlers=java.util.logging.ConsoleHandler, org.apache.juli.FileHandler
org.apache.juli.FileHandler.level=ALL
org.apache.juli.FileHandler.directory=${catalina.base}/logs
org.apache.juli.FileHandler.prefix=new-xyz-test-
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
com.xyz.level=ALL
com.xyz.handlers=org.apache.juli.FileHandler
To configure JULI in the web applications you need have a logging.properties file in the WEB-INF/classes directory. If you use the default handlers, you may lose messages. You need to specify a prefix for the handler in your file.
handlers=1FILE.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers=java.util.logging.ConsoleHandler
1FILE.org.apache.juli.FileHandler.level=FINEST
1FILE.org.apache.juli.FileHandler.directory=/app-logs
1FILE.org.apache.juli.FileHandler.prefix=file-1
java.util.logging.ConsoleHandler.level=FINE
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
com.xyz.level=INFO
com.xyz.handlers=1FILE.org.apache.juli.FileHandler
com.abc.level=INFO
com.abc.handlers=java.util.logging.ConsoleHandler
A
handler prefix (e.g. 1FILE.) starts with a number, then has an arbitrary string, and ends with a period (.).
See more in Logging in Tomcat
Arguments in the JVM
If you are not running the Tomcat from the startup.sh or startup.bat, you need to specify:
The location of the general logging.properties for Tomcat (in the conf directory of Tomcat)
The manager org.apache.juli.ClassLoaderLogManager. This is important because allows you to configure
for each web application different loggin options. By default, a JVM process can only have a single configuration file.) ,
Similar to the next (I'm using eclipse):
-Djava.util.logging.config.file="C:\Users\Paul\workspaces\utils\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\conf\logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
By default, java.util.logging read the file that is included in the JDK or JRE, e.g.:
"C:\Software\jdk1.7.0_17\jre\lib\logging.properties"
Setting Tomcat Heap Size (JVM Heap) in Eclipse, for how to add arguments in the VM
are you sure that you write to the correct logger , i.e. Logger.getLogger("com.xyz")?
I think that you may got wrong when you wrote in logging.properties:com.xyz.level=ALL com.xyz.handlers=org.apache.juli.FileHandler in the case that you actually write to the logger Logger.getLogger(com.xyz.YourClass.class), that because in the logging properties file you should write the logger name which is in your case com.xyz.YourClass