I have a logback configuration which specifies a daily rollover for a java swing application that is connected to a legacy backend and creates much log: <appender name="LocalFile" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${logdir}/local.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>${logdir}/local.%d{yyyy-MM-dd}.log</fileNamePattern> <!-- keep 10 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%t] %-5p %c{2} - %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>INFO</level> </filter> </appender> I am finding in production that sometimes the logfile doesn't roll. I am not sure whether the application is running at the moment when it's supposed to roll, if that matters. Initially I suspected Windows 7 permissions - a bloody nightmare - were responsible. I initially thought that it always rolled correctly on some machines, but not on others. But now I find a case on a single machine where rollovers happened on some days but not on others. We are using logback v.1,0.7 and slf4j version 1.6.5. Yes, I know there are more recent versions but it would be a major hassle getting them deployed into our particular environment and I haven't seen this behavior in months of testing. Can anyone point me in a direction leading to the solving of this issue?
Every time this has happened to me the root cause has been a permissions problem. Do you have a means to tailing standard out/err to see if the tell tale "permissions" problem is showing up there? Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll. On Wed, Jun 5, 2013 at 10:18 AM, Steve Cohen <scohen@javactivity.org> wrote:
I have a logback configuration which specifies a daily rollover for a java swing application that is connected to a legacy backend and creates much log:
<appender name="LocalFile" class="ch.qos.logback.core.**rolling.RollingFileAppender"> <File>${logdir}/local.log</**File> <rollingPolicy class="ch.qos.logback.core.**rolling.** TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>${logdir}/** local.%d{yyyy-MM-dd}.log</**fileNamePattern> <!-- keep 10 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%t] %-5p %c{2} - %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.** filter.ThresholdFilter"> <level>INFO</level> </filter> </appender>
I am finding in production that sometimes the logfile doesn't roll. I am not sure whether the application is running at the moment when it's supposed to roll, if that matters. Initially I suspected Windows 7 permissions - a bloody nightmare - were responsible. I initially thought that it always rolled correctly on some machines, but not on others. But now I find a case on a single machine where rollovers happened on some days but not on others.
We are using logback v.1,0.7 and slf4j version 1.6.5. Yes, I know there are more recent versions but it would be a major hassle getting them deployed into our particular environment and I haven't seen this behavior in months of testing.
Can anyone point me in a direction leading to the solving of this issue? ______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
"When the trigger is me"? What does this mean? I had thought that the rollover would happen whenever the day (in my case) crossed the boundary from the last entry. But that could easily be wrong.
Have you looked at the changes since 1.0.7 to see if any apply? Lack of rolling is curtly a difficult one to debug. Best way is to configure one roll per minute or more often and do a soak test. Roll at startup is discussed here. http://stackoverflow.com/questions/2492022/how-to-roll-the-log-file-on-start... David On 5 Jun 2013, at 18:46, Steve Cohen <scohen@javactivity.org> wrote:
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
"When the trigger is me"? What does this mean? I had thought that the rollover would happen whenever the day (in my case) crossed the boundary from the last entry. But that could easily be wrong.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hmm, I have rolled my own roll-on-startup policy but that is not, as written compatible with a roll-by-day setup, as it uses different file naming conventions. I use it for personal debugging but not in production. I'm not sure it's possible to combine the two in a single policy, if in fact, the default time-based policy does NOT roll on startup the app wasn't running at the boundary crossing. Can I get a definitive answer on whether the default time-based policy will roll on startup if the application wasn't running at the boundary crossing? On 06/05/2013 12:59 PM, David Roussel wrote:
Have you looked at the changes since 1.0.7 to see if any apply?
Lack of rolling is curtly a difficult one to debug. Best way is to configure one roll per minute or more often and do a soak test.
Roll at startup is discussed here. http://stackoverflow.com/questions/2492022/how-to-roll-the-log-file-on-start...
David
On 5 Jun 2013, at 18:46, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
"When the trigger is me"? What does this mean? I had thought that the rollover would happen whenever the day (in my case) crossed the boundary from the last entry. But that could easily be wrong.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
It's not definitive but there is an open bug for roll on startup. http://jira.qos.ch/browse/LOGBACK-204 Only thing definitive is the source code. David On 5 Jun 2013, at 19:26, Steve Cohen <scohen@javactivity.org> wrote:
Hmm, I have rolled my own roll-on-startup policy but that is not, as written compatible with a roll-by-day setup, as it uses different file naming conventions. I use it for personal debugging but not in production. I'm not sure it's possible to combine the two in a single policy, if in fact, the default time-based policy does NOT roll on startup the app wasn't running at the boundary crossing.
Can I get a definitive answer on whether the default time-based policy will roll on startup if the application wasn't running at the boundary crossing?
On 06/05/2013 12:59 PM, David Roussel wrote:
Have you looked at the changes since 1.0.7 to see if any apply?
Lack of rolling is curtly a difficult one to debug. Best way is to configure one roll per minute or more often and do a soak test.
Roll at startup is discussed here. http://stackoverflow.com/questions/2492022/how-to-roll-the-log-file-on-start...
David
On 5 Jun 2013, at 18:46, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
"When the trigger is me"? What does this mean? I had thought that the rollover would happen whenever the day (in my case) crossed the boundary from the last entry. But that could easily be wrong.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
On 5 Jun 2013, at 19:32, Steve Cohen <scohen@javactivity.org> wrote:
Have you looked at the changes since 1.0.7 to see if any apply? Is there a place where these are listed?
I may be wrong but it looks like this could be the solution to our problem: http://jira.qos.ch/browse/LOGBACK-92 If I just turn this property on, it could give me what I need. Or am I misunderstanding something? On 06/05/2013 01:35 PM, David Roussel wrote:
On 5 Jun 2013, at 19:32, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
Have you looked at the changes since 1.0.7 to see if any apply?
Is there a place where these are listed?
http://logback.qos.ch/news.html
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Yes that could be it. But note that in the comments of LOGBACK-204 someone notes that clean at startup is not the same as roll at startup. But anyhow it might be enough for you. David On 5 Jun 2013, at 19:51, Steve Cohen <scohen@javactivity.org> wrote:
I may be wrong but it looks like this could be the solution to our problem:
http://jira.qos.ch/browse/LOGBACK-92
If I just turn this property on, it could give me what I need. Or am I misunderstanding something?
On 06/05/2013 01:35 PM, David Roussel wrote:
On 5 Jun 2013, at 19:32, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
Have you looked at the changes since 1.0.7 to see if any apply? Is there a place where these are listed?
http://logback.qos.ch/news.html
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
How does one debug windows permissions - just to even see what they are? I tried cacls and I see all these terms like FILE_READ_ATTRIUTES, FILE_WRITE_EA, etc. which as far as I can tell are not defined ANYWHERE I can find on the web. Does anyone know what Windows 7 permission(s) would be necessary for a user to have in order for the rollover function of logback to work? I assume that it is doing a rename (or move) operation. On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Every time this has happened to me the root cause has been a permissions problem. Do you have a means to tailing standard out/err to see if the tell tale "permissions" problem is showing up there?
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
On Wed, Jun 5, 2013 at 10:18 AM, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
I have a logback configuration which specifies a daily rollover for a java swing application that is connected to a legacy backend and creates much log:
<appender name="LocalFile"
class="ch.qos.logback.core.__rolling.RollingFileAppender"> <File>${logdir}/local.log</__File> <rollingPolicy class="ch.qos.logback.core.__rolling.__TimeBasedRollingPolicy"> <!-- daily rollover -->
<fileNamePattern>${logdir}/__local.%d{yyyy-MM-dd}.log</__fileNamePattern> <!-- keep 10 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%t] %-5p %c{2} - %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.__filter.ThresholdFilter"> <level>INFO</level> </filter> </appender>
I am finding in production that sometimes the logfile doesn't roll. I am not sure whether the application is running at the moment when it's supposed to roll, if that matters. Initially I suspected Windows 7 permissions - a bloody nightmare - were responsible. I initially thought that it always rolled correctly on some machines, but not on others. But now I find a case on a single machine where rollovers happened on some days but not on others.
We are using logback v.1,0.7 and slf4j version 1.6.5. Yes, I know there are more recent versions but it would be a major hassle getting them deployed into our particular environment and I haven't seen this behavior in months of testing.
Can anyone point me in a direction leading to the solving of this issue? _________________________________________________ Logback-user mailing list Logback-user@qos.ch <mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/__listinfo/logback-user <http://mailman.qos.ch/mailman/listinfo/logback-user>
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Steve, The internal status messages are often very helpful in such circumstances. Did you set the debug attribute of the <configuration> element set to true? <configuration debug="true" ...> see also [1] and [2] [1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting [2] http://logback.qos.ch/manual/configuration.html#viewingStatusMessages On 05.06.2013 21:40, Steve Cohen wrote:
How does one debug windows permissions - just to even see what they are? I tried cacls and I see all these terms like FILE_READ_ATTRIUTES, FILE_WRITE_EA, etc. which as far as I can tell are not defined ANYWHERE I can find on the web.
Does anyone know what Windows 7 permission(s) would be necessary for a user to have in order for the rollover function of logback to work? I assume that it is doing a rename (or move) operation.
On 06/05/2013 12:35 PM, Robert Kuhar wrote:
Every time this has happened to me the root cause has been a permissions problem. Do you have a means to tailing standard out/err to see if the tell tale "permissions" problem is showing up there?
Also, if your app isn't running when the trigger is me, it is my understanding and observation that the logs won't roll.
On Wed, Jun 5, 2013 at 10:18 AM, Steve Cohen <scohen@javactivity.org <mailto:scohen@javactivity.org>> wrote:
I have a logback configuration which specifies a daily rollover for a java swing application that is connected to a legacy backend and creates much log:
<appender name="LocalFile"
class="ch.qos.logback.core.__rolling.RollingFileAppender"> <File>${logdir}/local.log</__File> <rollingPolicy class="ch.qos.logback.core.__rolling.__TimeBasedRollingPolicy"> <!-- daily rollover -->
<fileNamePattern>${logdir}/__local.%d{yyyy-MM-dd}.log</__fileNamePattern> <!-- keep 10 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d [%t] %-5p %c{2} - %m%n</pattern> </encoder> <filter class="ch.qos.logback.classic.__filter.ThresholdFilter"> <level>INFO</level> </filter> </appender>
I am finding in production that sometimes the logfile doesn't roll. I am not sure whether the application is running at the moment when it's supposed to roll, if that matters. Initially I suspected Windows 7 permissions - a bloody nightmare - were responsible. I initially thought that it always rolled correctly on some machines, but not on others. But now I find a case on a single machine where rollovers happened on some days but not on others.
We are using logback v.1,0.7 and slf4j version 1.6.5. Yes, I know there are more recent versions but it would be a major hassle getting them deployed into our particular environment and I haven't seen this behavior in months of testing.
Can anyone point me in a direction leading to the solving of this issue?
-- Ceki 65% of statistics are made up on the spot
On 06/05/2013 02:46 PM, ceki wrote:
Hi Steve,
The internal status messages are often very helpful in such circumstances. Did you set the debug attribute of the <configuration> element set to true?
<configuration debug="true" ...>
see also [1] and [2]
[1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting [2] http://logback.qos.ch/manual/configuration.html#viewingStatusMessages
Thanks, Ceki. However 1) this is Swing app running under javaw so there is no console. and it's not a web app so no easy way to hook up the servlet. 2) Corporate security prevents me from having access to production machines and I have a low degree of confidence that the environment I do have access to is similar to that of production. 3) and so, the only thing that could help me would be something like the OnConsoleStatusListener that wrote to a file instead of a console. Does anything like that exist?
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having access to production machines and I have a low degree of confidence that the environment I do have access to is similar to that of production.
3) and so, the only thing that could help me would be something like the OnConsoleStatusListener that wrote to a file instead of a console.
Does anything like that exist?
It's pretty trivial to write a status listener which sends its output to a file. Please have a look at [1] and [2]. [1] http://logback.qos.ch/manual/configuration.html#statusListener [2] http://logback.qos.ch/manual/configuration.html#logback.statusLC -- Ceki 65% f statistics are made up on the spot
On 06/05/2013 03:21 PM, ceki wrote:
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having access to production machines and I have a low degree of confidence that the environment I do have access to is similar to that of production.
3) and so, the only thing that could help me would be something like the OnConsoleStatusListener that wrote to a file instead of a console.
Does anything like that exist?
It's pretty trivial to write a status listener which sends its output to a file. Please have a look at [1] and [2].
[1] http://logback.qos.ch/manual/configuration.html#statusListener [2] http://logback.qos.ch/manual/configuration.html#logback.statusLC
Thanks, but this may not be necessary. I think I have replicated the problem in my development setting. It is indeed a permissions issue, caused by the @#$%^& Windows permissions system. I replicated it by switching to a minute rollover. At that point logged in as the owner of the file, the minute rollover works. Logged out as that user and logged in as a non-admin and started the program. The rollover failed to work. Now if I could only get some information about what the permissions need to be (good luck with the Microsoft websites), I could actually solve this. Does anyone reading this know the answer?
On 06/05/2013 04:46 PM, Steve Cohen wrote:
On 06/05/2013 03:21 PM, ceki wrote:
On 05.06.2013 22:15, Steve Cohen wrote:
1) this is Swing app running under javaw so there is no console. and it's not a web app so no easy way to hook up the servlet.
2) Corporate security prevents me from having access to production machines and I have a low degree of confidence that the environment I do have access to is similar to that of production.
3) and so, the only thing that could help me would be something like the OnConsoleStatusListener that wrote to a file instead of a console.
Does anything like that exist?
It's pretty trivial to write a status listener which sends its output to a file. Please have a look at [1] and [2].
[1] http://logback.qos.ch/manual/configuration.html#statusListener [2] http://logback.qos.ch/manual/configuration.html#logback.statusLC
Thanks, but this may not be necessary. I think I have replicated the problem in my development setting. It is indeed a permissions issue, caused by the @#$%^& Windows permissions system. I replicated it by switching to a minute rollover. At that point logged in as the owner of the file, the minute rollover works. Logged out as that user and logged in as a non-admin and started the program. The rollover failed to work.
Now if I could only get some information about what the permissions need to be (good luck with the Microsoft websites), I could actually solve this.
Does anyone reading this know the answer? _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I did see the the "rename error" message from logback in the console window in the environment I do have access to. It seems that the main logfile needs to have permissions of full rights for all users if multiple users are going to run the program, in order for this to work. Ironically, I have even found that an adminstrative user, who has the rights to delete or rename this file in Windows Explorer, even if he is not its "owner", does NOT have sufficient rights to rename it when running the application (part of the logback rollover process) if he is not its owner. Why would he be allowed to rename a file he doesn't own in the gui but not in java? Is this a bug in how logback (or java) performs the rename operation?
On 06/05/2013 05:32 PM, Steve Cohen wrote:
I did see the the "rename error" message from logback in the console window in the environment I do have access to.
It seems that the main logfile needs to have permissions of full rights for all users if multiple users are going to run the program, in order for this to work. Ironically, I have even found that an adminstrative user, who has the rights to delete or rename this file in Windows Explorer, even if he is not its "owner", does NOT have sufficient rights to rename it when running the application (part of the logback rollover process) if he is not its owner. Why would he be allowed to rename a file he doesn't own in the gui but not in java? Is this a bug in how logback (or java) performs the rename operation?
I think I've found my answer. It's at http://logback.qos.ch/codes.html#renamingError
On 06/05/2013 05:44 PM, Steve Cohen wrote:
I think I've found my answer. It's at http://logback.qos.ch/codes.html#renamingError
Although I can't quite see from the source how this suggestion works. But I will try it (tomorrow - it's been a long day).
On 06/05/2013 05:52 PM, Steve Cohen wrote:
Although I can't quite see from the source how this suggestion works. But I will try it (tomorrow - it's been a long day).
A closer look at source revealed how it works. And it works. I couldn't let it go and tried it. Documentation suggestion: not using the <File> attribute should be strongly recommended for use on the Windows platform, especially if the program is one that will be run by more than one user. Can't quite get my mind around what the developers of Windows had in mind when they decided that a user who is not the owner of the file should be allowed to write (append) to it, but not rename it. Or is this a limitation of java?
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion: not using the <File> attribute should be strongly recommended for use on the Windows platform, especially if the program is one that will be run by more than one user.
It is not just a question of more than one process holding the file open. File permissions may also prevent renaming and docs should mention this.
On 6/6/2013 2:22 AM, Steve Cohen wrote:
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion: not using the <File> attribute should be strongly recommended for use on the Windows platform, especially if the program is one that will be run by more than one user.
It is not just a question of more than one process holding the file open. File permissions may also prevent renaming and docs should mention this.
Hi Steve, I updated the docs to mention file permissions as well. http://logback.qos.ch/codes.html#renamingError Best regards, -- Ceki
Thank you! On 06/11/2013 10:46 AM, Ceki Gülcü wrote:
On 6/6/2013 2:22 AM, Steve Cohen wrote:
On 06/05/2013 07:06 PM, Steve Cohen wrote:
Documentation suggestion: not using the <File> attribute should be strongly recommended for use on the Windows platform, especially if the program is one that will be run by more than one user.
It is not just a question of more than one process holding the file open. File permissions may also prevent renaming and docs should mention this.
Hi Steve,
I updated the docs to mention file permissions as well.
http://logback.qos.ch/codes.html#renamingError
Best regards, -- Ceki _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (5)
-
ceki -
Ceki Gülcü
-
David Roussel -
Robert Kuhar -
Steve Cohen