Grails
  1. Grails
  2. GRAILS-2730

Location of stacktrace.log in WAR deployed app on Tomcat 6 running non-root is invalid

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.0.1, 1.0.2, 2.0-RC1
    • Fix Version/s: 2.1.4, 2.2.1, 2.3-M1
    • Component/s: Configuration
    • Labels:
      None

      Description

      Running grails 1.0.1 and Tomcat 6.0 war deployed. Tomcat is not running as root but as another user. This user has the appropriate permissions for the entire tomcat directory and temp areas.

      Upon startup this error occurs. When running tomcat as root the error does not occur.

      The location of the stacktrace.log should be configurable during the grails war process, or written somewhere relative from where the WAR is deployed.

      log4j:ERROR setFile(null,true) call failed.
      java.io.FileNotFoundException: stacktrace.log (Permission denied)
      at java.io.FileOutputStream.openAppend(Native Method)
      at java.io.FileOutputStream.<init>(FileOutputStream.java:177)
      at java.io.FileOutputStream.<init>(FileOutputStream.java:102)
      at org.apache.log4j.FileAppender.setFile(FileAppender.java:290)
      at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:164)
      at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:257)
      at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:133)
      at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:97)
      at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:689)
      at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:647)
      at org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:568)
      at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:442)
      at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:476)
      at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:471)
      at org.apache.log4j.LogManager.<clinit>(LogManager.java:125)
      at org.apache.log4j.Logger.getLogger(Logger.java:105)
      at org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:283)
      at org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:108)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
      at org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1040)
      at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:838)
      at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl

        Issue Links

          Activity

          Hide
          Peter Ledbrook added a comment -

          Some suggestions:

          1. Use logDir = new File(System.getProperty('catalina.home'), 'logs') (Tomcat-specific)
          2. Use java.io.tmpdir - sometimes too hard to track down
          3. Disable stacktrace.log in WAR mode
          4. Catch the permission exception and log a warning to configure the 'stacktrace' logger
          5. Log to console in WAR deploy mode

          The default should perhaps also include the name of the application in the filename, for the cases where a single container hosts more than one Grails app.

          Show
          Peter Ledbrook added a comment - Some suggestions: Use logDir = new File(System.getProperty('catalina.home'), 'logs') (Tomcat-specific) Use java.io.tmpdir - sometimes too hard to track down Disable stacktrace.log in WAR mode Catch the permission exception and log a warning to configure the 'stacktrace' logger Log to console in WAR deploy mode The default should perhaps also include the name of the application in the filename, for the cases where a single container hosts more than one Grails app.
          Hide
          Lari Hotari added a comment - - edited

          More solutions in the currently active email thread: http://grails.1312388.n4.nabble.com/stacktrace-log-tt4635524.html#a4635533 . I like Burt's solution for Tomcat. I usually add "appName" to the filename too.

          Show
          Lari Hotari added a comment - - edited More solutions in the currently active email thread: http://grails.1312388.n4.nabble.com/stacktrace-log-tt4635524.html#a4635533 . I like Burt's solution for Tomcat. I usually add "appName" to the filename too.
          Hide
          Alex Anderson added a comment -

          Have been bitten by this (last week, grails 2.0.3, Tomcat ??).

          Show
          Alex Anderson added a comment - Have been bitten by this (last week, grails 2.0.3, Tomcat ??).
          Hide
          Lari Hotari added a comment -

          Yet another stackoverflow question http://stackoverflow.com/a/12393628/166062 with solutions.

          Show
          Lari Hotari added a comment - Yet another stackoverflow question http://stackoverflow.com/a/12393628/166062 with solutions.
          Hide
          cdeszaq added a comment -

          This is still an issue in v2.2.0. At the very least, adding a commented out block to the logging configuration that either alerts the user to the potential issue when deploying, or better yet, provides a good solution that works in a multi-app tomcat install.

          I realize that logging is not slated to be dealt with quite yet, but sooner rather than later, since this seems to bite just about everyone who doesn't already know to look for it.

          Show
          cdeszaq added a comment - This is still an issue in v2.2.0. At the very least, adding a commented out block to the logging configuration that either alerts the user to the potential issue when deploying, or better yet, provides a good solution that works in a multi-app tomcat install. I realize that logging is not slated to be dealt with quite yet, but sooner rather than later, since this seems to bite just about everyone who doesn't already know to look for it.

            People

            • Assignee:
              Graeme Rocher
              Reporter:
              InterZ
            • Votes:
              16 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Last Reviewed:

                Development