[#JRA-13618] log4j logging to incorrect location on unix systems.

JIRA

log4j logging to incorrect location on unix systems.

Created: 26/Sep/07 10:15 AM Updated: Tuesday 07:08 AM

Component/s:

Backend / Domain Model

Affects Version/s:

3.9.3, 3.10.2

Fix Version/s:

3.13.x

Time Tracking:

Not Specified

Environment:

standalone running on Red Hat.

Participants:	Anton Mazkovoi [Atlassian], Bettina Zucker, Chace Daggers, John Washington and Sebastian Otaegui
Since last comment:	2 days ago
Labels:

Description

« Hide

Currently the log4j settings being shipped in the builds have the filelog pointing to wherever the startup script is called from.

I would suggest changing
log4j.appender.filelog.File=atlassian-jira.log

log4j.appender.filelog.File=${catalina.home}/logs/atlassian-jira.log

so that future releases drop the logs into the logs/atlassian-jira.log

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] added a comment - 26/Sep/07 09:29 PM

John,

Does ${catalina.home}/logs/atlassian-jira.log actually work? I think log4.j does not interpolate the ${catalina.home} variable as it does not know if it is running in Tomcat.

Please see Jeff's comment for the explanation:
http://jira.atlassian.com/browse/JRA-9769#action_77920

We would like to fix this problem once we implement JRA-1642.

I will resolve this issue for now. Please let me know if I missed the point and we will reopen it.

Cheers,
Anton

[ Permlink | « Hide ]

John Washington added a comment - 27/Sep/07 08:11 AM

This is working for my case (using the standalone build), perhaps this solution is only valid for the standalone versions of jira, but it really would be nice. I would note that this is how confluence is setup by default, so it may be worth changing in jira as well.

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] added a comment - 27/Sep/07 10:35 PM

John,

Thanks for the update.

We will take a look.

Cheers,
Anton

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] added a comment - 27/Sep/07 10:43 PM

John,

You are right, we can get it working for JIRA Standalone.

Cheers,
Anton

[ Permlink | « Hide ]

Chace Daggers added a comment - 05/Nov/07 04:24 PM

Anton | John:

To improve performance, use the storage report numbers generated by the RPTSTG run-time option as an aid in setting the initial and increment size for STACK.

One:
Chace ‡ |o|

[ Permlink | « Hide ]

Sebastian Otaegui added a comment - 22/May/08 11:52 PM - edited

Hello Anton

One cool feature of log4j is the posibilty of reading variables from command line, you can do stuff like:

Define a log4j.properties or .xml if its the case and do:

log4j.properties:
log4j.rootLogger=${log.level}, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

(tomcat example)
export JAVA_OPTS="${JAVA_OPTS} -Dlog.level=DEBUG"
startup.sh

And it will pick the loglevel from the defined variable.

[ Permlink | « Hide ]

Bettina Zucker added a comment - 26/Aug/08 07:08 AM

Changing the logfile path in log4j.properties may work, but it has an unwanted side effect.

When I start a Support Request the old location of the logfile is used, even after a jira restart.

Also when you look at the entry "Location of atlassian-jira.log" in "System Info" you get the old location.

This means, log4j puts its logfiles in the new path, but jira does not know about it!
As a result, an outdated logfile from the old path is added to a support request instead of the current logfile.

Cheers
Bettina Zucker