Reconfiguring log4j (part two)

[Doug Kelly]

Hi all,

I'm in part continuing a topic from over a year ago, where the initial issue (unable to pass a new log4j configuration in the container.javaOptions) has since been resolved:

https://groups.google.com/d/topic/repo-discuss/s8tCXgplW08/discussion

What I'm noticing now is how extremely painful it is to work up a "compatible" log4j.properties that does something akin to what the default settings produce.  I have a 94-line log4j.properties which is in part the log4j.properties shipped with Gerrit (gerrit-war/src/main/resources/log4j.properties), but also contains a fair amount to hook up the sshd_log, httpd_log, error_log, and gc_log, and direct the output to each accordingly.

So, where I'm going with this: should we ship an "example" configuration that people can use as a starting point should they need to override some of the log4j settings?  Or, should we contemplate some of the ideas Shawn proposed last year?  Obviously, 90+ lines of configuration just to turn down the verbosity on one message (I didn't need the replication status messages that got added recently) is a bit excessive, as well as slightly inflexible, because I didn't find a way (although I can't say one doesn't exist) to point to a relative path, such as ../logs/error_log, so I passed in absolute paths for each logfile.

It's nice being able to completely override the log4j.properties, and direct output as needed to different files.  At the same time, for someone who simply wants to turn down the noise slightly on one channel, Shawn's proposal to parse specific channels and set the levels accordingly makes the most sense -- that way, the remainder of the default logging can be set up automatically without having to reinvent the wheel.

Thanks!

--Doug

P.S. I'm willing to share the log4j.properties if anyone else is in a similar bind; it's not amazing, by any means, but it works.

[Doug Kelly]

Slightly related, but not completely: seems that after upgrading to 2.9, I've been getting a number of warnings for org.apache.sshd.server.channel.ChannelSession as clients (PuTTY) are requesting a channel the server doesn't support: win...@putty.projects.tartarus.org.  Unless anyone feels strongly, this might be another log channel to squelch a little. :)

[Alex Blewitt]

This is sent by putty to a server to try and dynamically adjust the size of the transmit window. Later versions of mina are supposed to handle thus more intelligently but in my experience this never worked properly and ssh throughout on windows is highly affected by latency. 

I think this particular warning is of little use to administrators when the solution is to either try later versions of mina or to ignore the problem. 

Alex

Sent from my iPhone 5

On 29 Sep 2014, at 16:01, Doug Kelly <doug...@gmail.com> wrote:

Slightly related, but not completely: seems that after upgrading to 2.9, I've been getting a number of warnings for org.apache.sshd.server.channel.ChannelSession as clients (PuTTY) are requesting a channel the server doesn't support: win...@putty.projects.tartarus.org.  Unless anyone feels strongly, this might be another log channel to squelch a little. :)

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Doug Kelly]

On Monday, September 29, 2014, Alex Blewitt <alex.b...@gmail.com> wrote:

This is sent by putty to a server to try and dynamically adjust the size of the transmit window. Later versions of mina are supposed to handle thus more intelligently but in my experience this never worked properly and ssh throughout on windows is highly affected by latency. 

Pretty much what I found. I didn't know mina has tried to add support for that; thanks!

 

I think this particular warning is of little use to administrators when the solution is to either try later versions of mina or to ignore the problem. 

This was what I was thinking. The warning is itself harmless, but it does decrease the signal to noise ratio in the logs. I use a combination of logstash, elasticsearch, and kibana to help manage and filter most of this for my day to day use, though.

Thanks!

[Alex Blewitt]

Yes, I think filtering out the noise would help. 

https://issues.apache.org/jira/browse/SSHD-256 is the related ticket, and claims that it’s been fixed in mina 0.10.0. Of course, it’s possible that the fix introduced the logging as well, in which case it should probably be reported as a bug to Mina to avoid logging in this case.

Alex

[Shivakumar Gopalakrishnan]

(bump)

I am in the similar situation. While running it under Kubernetes/Docker setup, we would like all log output to stdout/stderr without the default log rotation