Lazy java developers (or why I hate stack traces in logs)

This is an example of a successful imap login as seen in the mailbox.log in Zimbra. (one single line, though it is appearing word-wrapped here)


2008-05-18 01:10:24,999 INFO  [ImapSSLServer-2009] [name=sue@example.com;ip=1.2.3.4;] imap - user sue@example.com authenticated, mechanism=login

Compare what happens with a bad password (one nice log line followed by 20 lines of stack trace)


2008-05-18 01:10:25,109 WARN  [ImapSSLServer-2010] [ip=1.2.3.4;] imap - login failed
com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException: authentication failed for bob@example.com
Code:account.AUTH_FAILED
  at com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException.AUTH_FAILED(AccountServiceException.java:120)
  at com.zimbra.cs.account.AccountServiceException$AuthFailedServiceException.AUTH_FAILED(AccountServiceException.java:116)
  at com.zimbra.cs.account.ldap.AuthMechanism$ZimbraAuth.doAuth(AuthMechanism.java:112)
  at com.zimbra.cs.account.ldap.LdapProvisioning.verifyPasswordInternal(LdapProvisioning.java:2795)
  at com.zimbra.cs.account.ldap.LdapProvisioning.verifyPassword(LdapProvisioning.java:2768)
  at com.zimbra.cs.account.ldap.LdapProvisioning.authAccount(LdapProvisioning.java:2647)
  at com.zimbra.cs.account.ldap.LdapProvisioning.authAccount(LdapProvisioning.java:2626)
  at com.zimbra.cs.security.sasl.AuthenticatorUtil.authenticate(AuthenticatorUtil.java:25)
  at com.zimbra.cs.imap.ImapHandler.authenticate(ImapHandler.java:1012)
  at com.zimbra.cs.imap.ImapHandler.login(ImapHandler.java:988)
  at com.zimbra.cs.imap.ImapHandler.doLOGIN(ImapHandler.java:984)
  at com.zimbra.cs.imap.ImapHandler.executeRequest(ImapHandler.java:435)
  at com.zimbra.cs.imap.TcpImapHandler.processCommand(TcpImapHandler.java:151)
  at com.zimbra.cs.tcpserver.ProtocolHandler.processConnection(ProtocolHandler.java:160)
  at com.zimbra.cs.tcpserver.ProtocolHandler.run(ProtocolHandler.java:128)
  at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
  at java.lang.Thread.run(Thread.java:619)

WTF is the point with including all that java stack trace garbage in the log when it is a simple bad password?

Catch the bad password event, log it, and move on.

Do not dirty my logs with stupid stack traces that just fill up the disk and provide no value.

I see this in many other java products too, btw. Including where I am currently working. Gives me endless heartburn.

Lazy. Ass. Java. Propeller Heads. Learn to use Log4J or whatever and keep those stack traces for only really dire circumstances.

This entry was posted in General, System Administration, Work. Bookmark the permalink.

3 Responses to Lazy java developers (or why I hate stack traces in logs)

  1. Dumb. Ass. Java. Propeller Head. says:

    I own that code, and I agree that it’s completely asinine that we log a stack trace on simple auth failures. I’d always thought that at some point I’d edited it out and the support folks had made me put it back in. But I just checked the source control history… and that line of code has never once budged since the first IMAP checkin. I’ve been pissed off for years that I wasn’t supposed to remove that line, and, uh, yeah. It’ll be gone in 5.0.7.

    So… thanks for the rant. Dickhead.

  2. Trever says:

    Glad to be of service! Thank you for fixing this.

    Much more effective than logging an official bug, methinks. LOL.

  3. Michael says:

    Sweet, a new way to get developers to remove dodgy bits from otherwise good products. Just piss him off enough. Seriously though I use comm edition at home and I’ve always banged my head at the excessive stack dumps, it makes it really hard for an admin to discover some tiny bugs like disk permissions or wrong passwords.

Leave a Reply

Your email address will not be published.