In our projects we have a strange problem with duplicate log entries in the log file.
We have multiple appenders but a single logger.
If the spring boot application is started on local machine using java -jar the problem is not reproducible.
The problem occurs only when the application started as a service.
How can i solve the problem.
The problem occurs only if a file appender configured and if the spring boot application started using /etc/init.d/ symlink.
The spring boot's default start script redirects all console logs into the configured log file.
As a result both the logback logger and start scripts writes in the same file, thus we see duplicate entries in the log file.
Using systemctl (or setting the LOG_FILE or LOG_FOLDER environment variables) will solve this problem.
If you cannot switch to systemd you can set the environment variables so that all stdout&stderr messages redirected to /dev/null:
export LOG_FOLDER=/dev
export LOG_FILENAME=null
Related
I need, for performance reasons, get rid of org.jooq.tools.LoggerListener DEBUG log messages in Spring Boot application running inside Docker. None of the Spring Boot options like (Docker) env variable LOGGING_LEVEL_ORG_JOOQ=INFO in docker-compose.yml or Java system property -Dlogging.level.org.jooq=INFO passed to docker container in entry.sh do not remove these DEBUG messages reporting query execution details. Both option have been checked at Docker container level.
Even custom logback-perf.xml conf file, as in https://github.com/jOOQ/jOOQ/blob/master/jOOQ-examples/jOOQ-spring-boot-example/src/main/resources/logback.xml with DEBUG->INFO, pointed by LOGGING_CONFIG env var from docker-compose.yml does not prevent these debug messages. I have verified that the custom logback-perf.xml conf file is in use by changing appender patterns.
The best way to remove those messages in jOOQ directly, is to specify Settings.executeLogging = false, see here.
Obviously, there are also ways to set up loggers correctly, but I cannot see what you did from your description, or why that failed.
I have a spring boot app (1.5.10.RELEASE) that logs great when running as a standalone application in Eclipse IDE. I am using spring config and the properties file says this:
logging.level.com.myco.impl=DEBUG
logging.path=/log/myService
When I run as a standalone application, I see everything I see logged to the console and to a file in the above directory (called spring.log).
I then build my "uber jar" and run in like this:
java -jar my-service-0.1.0.jar. I see all the console logging just like running in IDE. I can see it looking for my configuration in spring config but I do not see any log file created.
I could use some ideas on what to look at.
In short - I (almost :-) ) believe that you have not set proper permissions on the logging path as pointed in the comments. The logging configurations seem quite simple and are described here. You can't get these wrong easily and yours seem OK.
The tricky part is how to diagnose the exact problem. For example on my system if I change the owner of the logging directory I can reproduce the behaviour with the uber jar that you described.
Next - I guess we both use slf4j with logback (e.g. coming because of spring-boot-starter). The laziest and quickest approach to understand what's wrong is to print the logback status messages as explained here. For example - programatically - there are other options too but I'll take the dirtiest :-) . Put this somewhere in your code:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
// print logback's internal status
StatusPrinter.print(lc);
LOGGER.debug("Some other message");
If I do that in my sample app (boot 1.5.10.RELEASE) I can immediately see the problem printed in the console along with many more status messages:
23:23:07,857 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - openFile(/tmp/so/spring.log,true) call failed. java.io.FileNotFoundException: /tmp/so/spring.log (Permission denied)
at java.io.FileNotFoundException: /tmp/so/spring.log (Permission denied)
See comments above. I did not include a jar I needed that was critical for reinitializing the logging system once it contacted spring cloud.
The issue may be a bug in Spring Boot 1.5.10, see:
https://github.com/spring-projects/spring-boot/issues/11951
I've faced similar issue when application cannot run, because log file was owned by root user and not available to change by application user.
Try to upgrade Spring Boot to 1.5.11 -- issue fixed in this version.
I've a set of applications installed on a server that I want to start sending logs thru syslog to a remote Logstash server. For that, I've created a single external Logback configuration file containing a SyslogAppender pointing to the desired remote server.
As multiple applications will log to the same server, I've changed the log pattern to be the following:
<suffixPattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [${server_instance}] [${application_name}] %p ${PID:- } --- [%15.15t] %logger : %m%n</suffixPattern>
Where server_instance and application_name are command-line option arguments provided at startup.
Now I just simply set the logging.config property of all my apps pointing to the same Logback config file, and all the applications start sending the logs using the specified pattern to the desired server. That part works like a charm.
But the only problem I've is that Logback isn't able to determine the server_instance and the application_name properties and they appear as [server_instance_IS_NOT_DEFINED] and [application_name_IS_NOT_DEFINED] respectively.
Can I achieve this somehow using a single external configuration file?
Logback isn't able to see command-line arguments; those are seen by Spring alone.
Moved those command-line options arguments to system properties (i.e. "-Dserver_instance" and "-Dapplication_name" instead of "--server_instance" and "--application_name") and now everything's working as expected.
I tried to start my spring boot application on centos server with this command line.
SPRING_PROFILES_ACTIVE=prd java -jar ./build/libs/port_switcher-0.0.1-SNAPSHOT.jar
But I got an error message that the port is already in used.
then looked up process list which is used in the port number using netstat
but there is no process that uses the port number
and then I rerun my spring boot application without SPRING_PROFILES_ACTIVE variable. (it was an mistake that forget that variable)
at that time spring boot application run successfully.
I really want to know what problem is in my application properties
this command occur error
SPRING_PROFILES_ACTIVE=prd java -jar ./build/libs/port_switcher-0.0.1-SNAPSHOT.jar
this command works fine
java -jar ./build/libs/port_switcher-0.0.1-SNAPSHOT.jar
application-prd.properties
#Server
server.address=xxx.xxx.xxx.xxx
server.port=9090
#Devtools
spring.devtools.livereload.enabled=true
spring.devtools.restart.enabled=true
# Logging
logging.level.org.springframework.web=INFO
logging.level.com.kakao.portswitcher=INFO
logging.path=logs
server.tomcat.basedir=./
server.tomcat.accesslog.enabled=true
#server.tomcat.accesslog.file-date-format=.yyyy-MM-dd
server.tomcat.accesslog.rotate=true
server.tomcat.accesslog.suffix=.log
server.tomcat.accesslog.prefix=access
server.tomcat.accesslog.directory=logs
server.tomcat.accesslog.buffered=true
#Jackson
spring.jackson.property-naming-strategy=SNAKE_CASE
# Status check file
status.file=./port_switcher_status
Can you try this :
java -jar -Dspring.profiles.active=prd ./build/libs/port_switcher-0.0.1-SNAPSHOT.jar
I am getting this error when running a Spring Batch Admin template project created via STS 3.2 on vanilla Tomcat 6/7 on RedHat Linux:
Could not load properties; nested exception is java.io.FileNotFoundException: class path resource [batch-L.properties] cannot be opened because it does not exist
I have no idea where that file is coming from. I tried searching for the file but to no success. Also, I need to add, that when running the same *war file on my local machine, everything works fine.
I will be grateful for any help.
Spring Batch Admin uses a system variable ENVIRONMENT to determine what properties file to load. By default, (if the variable isn't set), it will look for an HSQLDB version named batch-hsqldb.properties. In your case, it looks like the ENVIRONMENT variable is being set to the letter L.