[
https://issues.apache.org/jira/browse/LOG4J2-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16779793#comment-16779793
]
Jeff Gullett commented on LOG4J2-2238:
--------------------------------------
Ralph, I tried to add the "createOnDemand" property to my appenders, but Log4j
still crashes. I think it is because I am using asynchronous logging, and it
appears the logger is trying to flush the log (which tries to create the
FileOutputStream), even though nothing has as yet been written to the log.
To answer your other question, as to why this *is* in fact a bug, I will use an
analogy. Let's say I ask you to deliver a package to the front porch of my
house. You get to my house, and the front door is locked. Do you think it is
OK for you to say, "sorry, I didn't deliver the package on your front porch
because the front door was locked"? If so, then I think we are at an impass,
and there is nothing I can say or do to convince you this is an issue with
Log4j.
If, like me, you think the front door being locked is inconsequential to
whether or not you deliver the package on my front porch, then read on. Now,
if my property were fenced, and the gate on my fence were locked, then I would
agree: it wouldn't be your fault for not delivering my package, since you had
no way to access my front porch.
The former is the situation on my machine. You are correct, Log4j doesn't have
permission to write to the log file. However, I explicitly told Log4j (via
OnStartupTriggeringPolicy configuration) to move the existing log file, then
create a new one before trying to write anything to the log. The directory in
which the log exists is world-editable, meaning the front gate is unlocked. If
I execute "mv myLogFile.txt myLogFile2.txt" on the command line, the command
succeeds, and the file is renamed. The fact that I can't write to the file has
no bearing on whether or not I can move the file.
Despite this fact, Log4j isn't following my configuration instructions. I
configured Log4j to use a new log file every time I start my application.
Instead, Log4j is trying to open the existing file for write, which prevents my
application from logging properly. In my mind, this is a bug, and what this
issue was created to address. If that description still remains unclear, I can
try to explain further, but I'm struggling to understand why you think not
having write permissions to the file is relevant.
> Insufficient Permissions Error when Rolling Log Files
> -----------------------------------------------------
>
> Key: LOG4J2-2238
> URL: https://issues.apache.org/jira/browse/LOG4J2-2238
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.9.1
> Environment: CentOS 6.6 (32-bit)
> Java 8u151 (32-bit)
> Reporter: Jeff Gullett
> Priority: Minor
> Labels: Linux, permissions, unix
> Fix For: 2.12.0
>
>
> I have an application utilizing Log4j2 using a rolling file appender. Within
> each appender, I set the log file permissions using the new "filePermissions"
> attribute to be 644 (rw-r--r--). If I run my application as "root", then try
> to run as any other user, I receive an error with the text (Note: ... ==
> "org.apache.log4j.core."):
> ERROR RollingFileManager (/var/log/myApp/Info.log)
> java.io.FileNotFoundException: /var/log/myApp/Info.log (Permission denied)
> java.io.FileNotFoundException: var/log.myApp/Info.log (Permission denied)
> at java.io.FileOutputStream.open0 (Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
> at java.io.FileOutputStream.<init>(FileOutputStream.java:133)
> at
> ...appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:640)
> at
> ...appender.rolling.RollingFileManager$RollingFileManagerFactory.createManager(RollingFileManager.java:608)
> at ...appender.AbstractManager.getManager(AbstractManager.java:113)
> at
> ...appender.OutputStreamManager.getManager(OutputStreamManager.java:188)
> ...
> My configuration file is like the following:
> {code:xml}
> <?xml version="1.0" encoding="utf-8"?>
> <Configuration>
> <Appenders>
> <RollingFile name="InfoLog" fileName="/var/log/myApp/Info.log"
> filePattern="/var/log/myApp/Info%d\{yyyy-MM-dd}.%i.log"
> filePermissions="rw-r--r--">
> <Policies>
> <OnStartupTriggeringPolicy />
> <TimeBasedTriggeringPolicy modulate="true" />
> <SizeBasedTriggeringPolicy size="16MB" />
> </Policies>
> <DefaultRolloverStrategy max="9999">
> <Delete basePath="/var/log/myApp">
> <IfLastModified age="365d" />
> </Delete>
> </DefaultRolloverStrategy>
> </RollingFile>
> </Appenders>
> <Loggers>
> <Rool level="debug">
> <AppenderRef ref="InfoLog" level="info" />
> </Root>
> </Loggers>
> </Configuration>
> {code}
> I have verified that the permissions on "/var/log/myApp" are 777 (rwxrwxrwx).
> I have also verified that as a non-root user, I am able to move an existing
> log file (e.g., "mv Info.log Info_Archive.log" works when running as non-root
> user, even though running my application as that user results in the
> aforementioned error). My expectation is that the file would be moved, a new
> file created, then the output stream opened. However, it appears from the
> error that the output stream is opened, then the log file renamed, and
> finally a new log file created and opened. A work-around for this issue is
> to create log files with 777 permissions, but I don't want to give all users
> full permission to my log files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
