Value for limit size of logfile

[trac@…]

It would be great if TRAC would able rotate logfiles exceeding a size limit.

It means: I want able to say don't let logfiles get bigger than 10MB, if size is reached, rotate them count times. So if count is set to 5, then it will get rotated up to log.5.

This would very handy when running in debug mode when something goes wrong not often and so debug-logging must run a long time and this stuff shouldn't go into syslog.

[Emmanuel Blot]

This is out-of-scope. If you need to rotate a log script, use a dedicated tool, such as logrotate.

They are several great tool out there that do these jobs really good, I don't think it is worth adding a custom, less-powerful implementation to Trac.

[Christian Boos]

I wonder… would logrotate work well with the python logger? IOW, what happens with long running scripts, do they keep an open descriptor on the log file?

Alternatively, implementing this could be as simple as using a ​RotatingFileHandler for the log.

[Emmanuel Blot]

Replying to cboos:

Alternatively, implementing this could be as simple as using a ​RotatingFileHandler for the log.

Maybe as a plugin? I think we should refrain from adding these extra features to the core. As long as Trac is able to use syslog as an output - and therefore takes advantages of the various and existing tools, IMHO we don't have to care about these features with Trac.
There are already too many things to implement, most of them are features that cannot be handled with existing tools…

[trac@…]

Replying to eblot:

This is out-of-scope. If you need to rotate a log script, use a dedicated tool, such as logrotate.

They are several great tool out there that do these jobs really good, I don't think it is worth adding a custom, less-powerful implementation to Trac.

Not every user of trac is the maintainer of a system where setting up of a logrotation is possible. There are millions of webserver where millions of domains are hosted, each may setup a trac. Without access to the system itself and logrotation. The times trac is used only inside small environments where the trac-user is the same like the sysadmin is over.

You should meanwhile care about it.

And not every system where trac is running has a powerfull logrotate.

So this is not out-of-scope, this should get a part of Trac. Every long running daemon (them inside webservers, too) uses meanwhile some techniques for that stuff. For the reasons described above. And logrotation isn't hard to implement.

As plugin? Why not. The way how it may enabled or disabled isn't important. So please don't simply close this request but think with some others about if it wouldn't interesting to others and/or futures systems and installations of TRAC.

[Christian Boos]

patch welcomed ;-)

[trac@…]

Patch against ​http://svn.edgewall.org/repos/trac/branches/0.10-stable revision 6080

[trac@…]

See patch, quick'n dirty, works, short tested, rotate size in MB. May finetuned for 0.10.5 ?

[Emmanuel Blot]

Replying to trac@alwins-world.de:

See patch, quick'n dirty, works, short tested, rotate size in MB. May finetuned for 0.10.5 ?

That would be for branch 0.11 as it's a new feature, and we should avoid any new feature in 0.11, so at best target is 0.11.1.
BTW, your patch contains a lot of empty line changes…

[Christian Boos]

Thanks! I cleaned up a bit the patch - please next time avoid introducing spurious whitespace changes.

[Christian Boos]

Manu, sorry, I didn't see your previous comment. That's typically the no risk change that are worthwhile adding in a stable release IMO. Do you really want to object to it for 0.10.5?

[Christian Boos]

White-space cleanup of the previous patch and Since 0.10.5 info

[Emmanuel Blot]

Replying to cboos:

Manu, sorry, I didn't see your previous comment. That's typically the no risk change that are worthwhile adding in a stable release IMO. Do you really want to object to it for 0.10.5?

IMHO:

• I though the rules to add some code to the stable branch was about bug fixing or security issue only. Adding a new feature usually adds new bugs, whatever the quality of the code.
• We do not have the bandwidth right now to really test this feature:
  • what will happen if the new log file can't be created? Does the file keep growing, or does the web server end up in a fatal 'Internal server error' as when the initial log file can't be created? I'm not sure the latter is a real benefit over the former
  • what will happen when the server is heavily loaded? I don't know the behaviour of the RotatingFileHandler implementation - the documentation is pretty shy about multihreading support for example

I wish this extra feature would have been implemented as a plugin. Trac core is supposed to be kept small, as far as I understood. I consider the rotating log file feature as an extra feature - vs. a core one - because of the aforementionned points.

To sum up:

• I don't agree it is a "no risk change": IMHO we lack experience with this module for now
• I don't object to adding it to 0.10.5 though
• I wish other Trac developers give their feedback on this before the final decision (commit) is made.

[Christian Boos]

Come on, not everything can be implemented as a plugin! Here we're dealing with the logging system which gets initialized before the plugin system itself (well, before the plugins are loaded, at least).

About the possible problems you raised:

• the feature has to be enabled explicitly, so it's likely that the administrator will try to test the log rotation he has just enabled. If not and there's an issue with creating the files, then hopefully he'll remember what he did. If not… well, bad luck ;-)
• Multithreading concern would apply for any logger, I'd be surprised if the FileHandler was thread-safe and the others not.

But I don't say there can't be any problem, as with any changes. So I don't insist on 0.10.5, I have no problem moving that to trunk so that it can get more testing. But 0.11.1 - well, that's a bit far away for such a simple thing, no?

[Emmanuel Blot]

Replying to cboos:

Come on, not everything can be implemented as a plugin! Here we're dealing with the logging system which gets initialized before the plugin system itself (well, before the plugins are loaded, at least).

Good point[[br]]It's still an extra feature from my perspective.

• the feature has to be enabled explicitly, so it's likely that the administrator will try to test the log rotation he has just enabled.

I would not bet on this one. Would you try to reduce the log file option to a small value for the simple purpose to see if the feature is not broken? I would not.

So I don't insist on 0.10.5, I have no problem moving that to trunk so that it can get more testing. But 0.11.1 - well, that's a bit far away for such a simple thing, no?

The patch is available from the ticket: if someone wants to use it, he can apply it.
Meanwhile, there is the logrotate feature, or one can also reduce the debug level, etc.

OTOH, you may get positive feedback from other developers quite soon, then apply it to 0.10.5 ;-)

[trac@…]

1. Sorry for the white-space-changes, forgot to check it (as I said - dirty and fast)
2. From a simple user point of view (like I have)
   • it is a problem that such a feature isn't existing.
   • as I saw the Rotating-class from python is something like other classes in logging of python, it is like the normal Filelogger with an extra feature.
   • except the problems with my whitespace-changes it isn't a big patch, it makes no sense waiting month for standard-installations getting it. Not every checks where to get something like this.

So it would nice if you just correct my whitespace-changes and -error and trust pythons library code, I think this rotating logger is tested enough from the python-community itself, it would realy great putting this few lines into the 0.10.5. :)

tnx

[anonymous]

Replying to eblot:

To sum up:

• I don't agree it is a "no risk change": IMHO we lack experience with this module for now
• I don't object to adding it to 0.10.5 though
• I wish other Trac developers give their feedback on this before the final decision (commit) is made.

+100 on keeping out of core. If it is even remotely possible for something to be a plugin, it should be. If later we see that literally everyone has this plugin installed, perhaps we can talk about core integration. This needs to become a general mantra of Trac development.