RackMultipart temp files

[Johan "Johnnei"]

Hello,

Since the upgrade to the LTS 5.6.1 (Still need to schedule a moment to upgrade to .3) every now and then the /tmp folder on the server gets piled up with 'RackMultipart<date>-<id>-<hash>' files which are near the same size of our zipped Analysis reports. For us this only happens on a 'busy night' when 'a lot' of branches have been updated and thus are analyzed during the night.

Now the annoying thing is that we can't seem to force those file to be stored in the configured temp folder (/data/sonar/temp set in sonar.path.temp) which resides on a much larger disk. After the last time we've added the 'java.io.tmpdir' explicitly to 'sonar.ce.javaOpts' and 'sonar.web.javaOpts', sadly to no benefit. The files still end up in /tmp.

The stacktrace in the logs:
2016.10.20 20:33:21 ERROR web[rails] /!\ FAILSAFE /!\  Thu Oct 20 20:33:21 +0200 2016
  Status: 500 Internal Server Error
  No space left on device
    org/jruby/RubyIO.java:1408:in `write'
    org/jruby/RubyIO.java:1565:in `<<'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/utils.rb:568:in `parse_multipart'
    org/jruby/RubyKernel.java:1519:in `loop'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/utils.rb:537:in `parse_multipart'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/request.rb:268:in `parse_multipart'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/request.rb:146:in `POST'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/methodoverride.rb:15:in `call'
    /opt/sonar/web/WEB-INF/gems/gems/actionpack-2.3.15/lib/action_controller/params_parser.rb:15:in `call'
    file:/opt/sonar/lib/server/jruby-rack-1.1.13.2.jar!/jruby/rack/session_store.rb:70:in `context'
    /opt/sonar/web/WEB-INF/gems/gems/rack-1.1.6/lib/rack/session/abstract/id.rb:58:in `call'
    /opt/sonar/web/WEB-INF/gems/gems/actionpack-2.3.15/lib/action_controller/failsafe.rb:26:in `call'
    /opt/sonar/web/WEB-INF/gems/gems/actionpack-2.3.15/lib/action_controller/dispatcher.rb:106:in `call'
    file:/opt/sonar/lib/server/jruby-rack-1.1.13.2.jar!/rack/adapter/rails.rb:34:in `serve_rails'
    file:/opt/sonar/lib/server/jruby-rack-1.1.13.2.jar!/rack/adapter/rails.rb:39:in `call'
    file:/opt/sonar/lib/server/jruby-rack-1.1.13.2.jar!/rack/handler/servlet.rb:22:in `call'

Now what I also find noticeable is that the temp files of the 19th are still around even though we had no issues with the CE reports on that day (No failed analysis submits and no exceptions in the logs). The reports of the 20th caused the /tmp partition to become full and thus the submits started failing.

Are there anymore configuration options we can try to tweak this behaviour? Or should I start considering to create a cronjob to clean up the old files?

Kind regards,

Johan.

[Sebastien Lesaint]

Hello Johan,

I think SONAR-7896 fixed in SQ 5.6.2 will cover your need. The problem was on Windows machines but the underlying cause was the Ruby stack not using the configured temp directory.

Until you upgrade, I think you could give a try to the workaround described in the ticket.

Cheers,

Sébastien LESAINT | SonarSource
Platform Developer

http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/6e675a76-9c71-445b-8f36-250b4dec2014%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johan "Johnnei"]

Hello Sébastien,

When looking at the ticket that indeed seems to fix the pathing issue our use-case. We'll configure the workaround until we've upgraded to SQ 5.6.3.
Thanks!

Kind regards,

Johan.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.