Defect #5706
closed
Default config.log_level is too verbose for production
0%
Description
The default config.log_level for production environments is too high. It is currently set at :info which adds in 4-5 lines of text into ./log/production.log for every single request. I see no reason anyone would want this information for a production environment.
It has actually caused me issues as my ./log/production.log file grew to over 4GiB, and when I restarted mongrel it failed to restart. After debugging I found out it was due to my max file size and this file was filled up because of Redmine.
I'd like to propose a default of :warn for production environments. We don't need all this :info text for production.
Related issues
Updated by Eric Davis over 14 years ago
- Status changed from New to Closed
- Resolution set to Wont fix
We discussed this on IRC, I don't understand why you felt you needed to open a bug for this. With the default setting of :info each request logs information about the request:
Processing WelcomeController#index (for 127.0.0.1 at 2010-06-17 14:49:33) [GET]
Parameters: {"action"=>"index", "controller"=>"welcome"}
Rendering template within layouts/base
Rendering welcome/index
Completed in 679ms (View: 636, DB: 5) | 200 OK [http://redmine.acheron/]
If it's changed to :warn, then nothing is logged for requests. This will not become the default option because:
1. If there is a bug or problem, you have no data to debug it or even report the bug. Without logs, bug reports are less valuable.
2. There is no way to tell how active your Redmine is or if it's working. Tailing the logs is the main way to tell when Redmine is under use.
If you want to change the log level for yourself, do it in additional_environment.rb. It will not be changed in the Redmine core.
Updated by Anonymous over 14 years ago
- Status changed from Closed to Reopened
I opened this as our discussion lead to you only backing up the points that I was making. Lets start by seeing what a production environment should be for, which is an environment setup for your application that gets served to its user base, be that users on the great wide Internet or those internally within your Intranet.
With this you want logs, agreed, logs are fantastic for when things go wrong. No (sane) sys admin wants logs that give nothing about what went wrong, which is what we have here. Why do I care, in a production environment, about every single request made (something that I and everyone else can get through their webserver)? I don't. All I want to know is when something goes wrong, errors or warnings that start to appear which tell me that something is either A) wrong with my server configuration B) wrong with my redmine installation.
This will not become the default option because:
None of these are valid reasons:
- Why do the logs at levels error and warning not provide enough data for you? If you need additional data from the user who reports a bug, you can kindly ask them to increase their log level. You mentioned about being unable to replicate (on IRC), which means there would be a bigger problem and/or the end user is at fault.
- Of course there is, the vast majority of web servers have the ability to log access requests by default. You're saying there is no way, well I break that rule every day when I look at my server logs.
It makes 100% no sense to log every single request which just fills up a single file on the web server. There is nothing to mention it is advised to setup log rotation for Redmine, therefor all this is doing is occupying vasts amount of space for no reason which can easily and quickly lead to problems.
I'm sorry but I would like to get some other users input before this blindly gets closed, hence the status change.
Updated by Robert Chady over 14 years ago
I'm a little puzzled at your attitude. Eric already told you how to fix the problem that you reported in your environment. Instead of being thankful, you are basically demanding that it be changed to the default. I consider it a very valid point that the default should be left so information is provided in case someone has a problem and needs support.
If you want to change this setting in your environment, that is fine, but don't demand that it be changed so it will be near impossible to help people new to Redmine with any issues.
Updated by Anonymous over 14 years ago
Robert Chady wrote:
I'm a little puzzled at your attitude. Eric already told you how to fix the problem that you reported in your environment. Instead of being thankful, you are basically demanding that it be changed to the default.
Thanks was given to the person who helped me out in the IRC channel, which wasn't originally Eric. Don't get me wrong, I appreciate Eric's contribution to the discussion which has let to this bug report. I may have been told how to fix it, however what about the other users? Bugs get fixed within Redmine, not patches handed out to the single person that reported the issue otherwise we'd get no where.
I consider it a very valid point that the default should be left so information is provided in case someone has a problem and needs support.
If you want to change this setting in your environment, that is fine, but don't demand that it be changed so it will be near impossible to help people new to Redmine with any issues.
Then why doesn't the logs at level warn, error and even fatal provide enough information? We're not guinea pigs and shouldn't be keeping this information by default. There is nothing wrong with asking the person who reports an issue to increase their log level to provide this information. But really, if setting the log level to warn makes it impossible to help new people, then there is a bigger problem.
Updated by Robert Chady over 14 years ago
Nobody said you were a guinea pig, but if you come asking for help, it is much easier to provide that help with useful information. This is even more so a case where something happened that you can't immediately reproduce.
Again, if you don't care for what the default log level is, change it. You have been told how to do it.
This by no means is a bug, it is intended behavior. Once again, if you don't like it, change it.
Updated by Anonymous over 14 years ago
Robert Chady wrote:
Nobody said you were a guinea pig, but if you come asking for help, it is much easier to provide that help with useful information. This is even more so a case where something happened that you can't immediately reproduce.
Then the person helping can ask they increase their log level.
Again, if you don't care for what the default log level is, change it. You have been told how to do it.
I think the fact I opened a bug report for this shows that I do care.
This by no means is a bug, it is intended behavior. Once again, if you don't like it, change it.
Intended behaviour does not make it the correct behaviour. I have changed it, to the far more sane :warn.
Updated by Felix Schäfer over 14 years ago
- Status changed from Reopened to Closed
Alex Cartwright wrote:
Intended behaviour does not make it the correct behaviour. I have changed it, to the far more sane :warn.
What is this "correct" behavior you are talking about? Do you have any stone tablet codifying that?
Anyway, the developers have made a decision and given arguments to support it, your disagreeing with it doesn't make it wrong (or right for that matter). This default will not be changed, period. If you so strongly disagree with it, feel free to fork, the software is OS after all, if not, leave it at that and let the developers spend their (free!) time one more important issues. What you could do if you so strongly feel about it and that could be helpful would be to edit the installation wiki page to reflect your findings and make other users aware of them.
Updated by Anonymous over 14 years ago
At the end of the day it is your decision, however I would like to know the real reasons behind this as default, that the developers talked about (I'm assuming you had a discussion about this bug?)?
Felix Schäfer wrote:
Anyway, the developers have made a decision and given arguments to support it, your disagreeing with it doesn't make it wrong (or right for that matter). This default will not be changed, period. If you so strongly disagree with it, feel free to fork, the software is OS after all, if not, leave it at that and let the developers spend their (free!) time one more important issues.
Just 1 more point to justify my reasoning; many hosts have a limit on the maximum file size that can be created (for example through /etc/security/limits.conf), so by logging all of these requests you are intentionally going to cripple Redmins logging facility because as soon as this file hits the maximum file size, Redmine will no longer be able to write to production.log. Your main argument being that these logs are very helpful - how can they be helpful if Redmine can no longer write to this file?
Not only will Redmine be unable to write to this file, but a restart of the server will result in Redmine being unable to start (as in my case, mongrel_rails was unable to start).
I'd just like to know the valid reasons to justify your decision.
What you could do if you so strongly feel about it and that could be helpful would be to edit the installation wiki page to reflect your findings and make other users aware of them.
Thanks, I shall to make people aware.
Updated by Felix Schäfer over 14 years ago
Alex Cartwright wrote:
At the end of the day it is your decision, however I would like to know the real reasons behind this as default, that the developers talked about (I'm assuming you had a discussion about this bug?)?
You have been given reasons, ignoring them because you don't deem them valid won't make them go :-)
Just 1 more point to justify my reasoning; many hosts have a limit on the maximum file size that can be created (for example through /etc/security/limits.conf), so by logging all of these requests you are intentionally going to cripple Redmins logging facility because as soon as this file hits the maximum file size, Redmine will no longer be able to write to production.log. Your main argument being that these logs are very helpful - how can they be helpful if Redmine can no longer write to this file?
Not only will Redmine be unable to write to this file, but a restart of the server will result in Redmine being unable to start (as in my case, mongrel_rails was unable to start).
I get your point, still doesn't invalidate the arguments for keeping the log level. By your rationale, no software should log anything unless asked to, what about apache, varnish, squid, exim and all the others? They also have the problems you are writing about, though they are mitigated in many distributions by the use of log rotators.
What you could do if you so strongly feel about it and that could be helpful would be to edit the installation wiki page to reflect your findings and make other users aware of them.
Thanks, I shall to make people aware.
Thanks :-)
Updated by Anonymous over 14 years ago
Felix Schäfer wrote:
You have been given reasons, ignoring them because you don't deem them valid won't make them go :-)
Saying the production.log file is the only way of seeing if your Redmine installation is being accessed is completely false which I and anyone else can prove. The only reason given left is that it provides information helpful to debug problems. That's fine, but this is for a production environment, you don't want that sort of info to debug.
I get your point, still doesn't invalidate the arguments for keeping the log level. By your rationale, no software should log anything unless asked to, what about apache, varnish, squid, exim and all the others? They also have the problems you are writing about, though they are mitigated in many distributions by the use of log rotators.
Logs which point to something not working are perfectly fine. Other applications such as Apache in most distributions are already setup for log rotation; yeah you could argue that Redmine has not been installed by a package in my distribution however there is no mention at all in the documentation that Redmine will log so verbosely.
All I'm trying to do is help others out who are going to run into this problem, as this is not a bug which will be seen straight away but will in the future.
Updated by Jean-Claude Wippler over 10 years ago
Don't want to pour oil on the fire (honestly), but there is an issue worth attending to, IMO.
Out of the box, the log grows as a monolithic file (I've had to chase this a few times on discovering a GB or more of unexpected disk use).
The "configuration.yml.example" file doesn't tell me how to change the log level, so all I can do is stop the server, delete the file, and restart.
A comment in the example config, or a rotation system so I can reduce disk use without stopping the server, or both would be helpful.
Updated by Jean-Claude Wippler over 10 years ago
Bump? Just saw that my production log is over 500 MB again.
Updated by Toshi MARUYAMA over 10 years ago
Jean-Claude Wippler wrote:
Bump? Just saw that my production log is over 500 MB again.
Updated by Toshi MARUYAMA over 10 years ago
- Related to Defect #6135: Default logger configuration grows without bound. added