Why doesn't SBT 0.7.7 work correctly on my Linux system? (case details inside)

Question

First of all, I'd like to ask to correct my question title if something better comes into your mind.

Let's take a Lift REST web service example from the Simply Lift book by David Pollak here.

If I open a Windows (Windows XP SP3, all the updates, Oracle JDK 7) console inside the directory and run "sbt" (sbt.bat), everything works just fine. But in case I try to do the same (but using "./sbt") in Linux (XUbuntu 11.10, OpenJDK 6, OpenJDK 7, Oracle JDK 7 (tried all of them)), SBT returns (instead of going to SBT console mode) immediately as it has done it's job. This means that may the command be just ./sbt it returns about immediately (after finishing the automatic project maintenance), or be it ./sbt jetty-run - it just starts the web server and shuts it down immediately.

Moreover, a web service I've developed for a project of mine compiles and works ok on Windows, but can't be compiled (using ./sbt compile) on Linux (by the same version of SBT). The error is "source file '/.../src/main/scala/code/lib/FooBar.scala;src/main/scala/bootstrap/liftweb/Boot.scala' could not be found", where "FooBar.scala" is an object where I do all the serves (directly called from Boot.scala).

Any ideas of what can be the reason and how to fix it?

UPDATE: The reason of the first problem (SBT returning to shell instead of offering SBT console) seems to be the file was checked out on Windows and had CR+LF instead of just LF line ending. The solution of source files not being found was in just using clean command to recompile from scratch.

Astrix

you've described a normal behavior for ./sbt jetty-run command. Try ./sbt ~jetty-run instead. – Noh

Thanks, @thomasmore. And how do I stop that jetty instance then? Anyway, I want ./sbt to get me into an SBT console! It works this way on Windows (exactly the same sbt-launch.jar!) and used to work this way on Linux when I was using it a year ago. – Astrix

It's usually enough to press enter to stop that jetty instance. You can press Ctrl-C/Ctrl-Z too. But I completely don't know what have happened with your sbt, so I can't help you with other problems. – Noh

What does your sbt start script look like? – Sofar

java -Xmx512M -Xss2M -XX:+CMSClassUnloadingEnabled -jar dirname $0/sbt-launch.jar "$@" – Astrix

What version of SBT are you using? – Utrillo

@Emil 0.7.7 for this project. – Astrix

Answer 1

The reason of the first problem (SBT returning to shell instead of offering SBT console) seems to be the file was checked out on Windows and had CR+LF instead of just LF line ending. The solution of source files not being found was in just using clean command to recompile from scratch.

Astrix

Answer 2

First what happens when you simply type:

java -jar sbt-launch.jar

directly from the command line in the folder where the sbt-launch.jar is placed ?. If the sbt-launch.jar is in the same folder as the sbt script then you can edit the script to look like this:

#!/bin/sh
test -f ~/.sbtconfig && . ~/.sbtconfig
java -Xmx512M ${SBT_OPTS} -jar dirname $0/sbt-launch.jar "$@" 

The dirname $0 construct returns the full path of the sbt script folder without the filename of the script. Using the $SBT_OPTS variable allows you to experiment with the various JVM options, like:

SBT_OPTS="-Xss2M -XX:+CMSClassUnloadingEnabled"

Although I would wait with these options as they are likely not the problem here (however be sure to add CMSClassUnloadingEnable later when SBT is working as it ensures that Scala class definitions generated dynamically when running SBT gets unloaded when they are unused, thus preventing memory errors - see more info here):

Also consider using one of

-Djline.terminal=scala.tools.jline.UnixTerminal

or even

-Djline.terminal=jline.UnsupportedTerminal

in your SBT_OPTS.

Finally what happens if you try a never version of SBT ? (you could try running the SBT 0.11 version of the lift example found here https://github.com/lacy/lift-quickstart).

Bechuanaland

You get the bounty to avoid wasting it, but the answer is different. – Astrix

Answer 3

Replace your Linux script by:

#!/bin/bash

java -Xmx512M -jar `dirname $0`/sbt-launch.jar "$@"

On your settings:

Your script sets Xss (the Thread stack size). In Linux you sometimes need to change (via ulimit) the settings for stack per thread (ulimit -s) as you may have conflicts at SO level which may be triggering the "kill" on your threads. Unless you have a very important reason to set this flag just remove it and let the JVM manage this.

It may also be you wanted to put Xms instead of Xss, although then 2M would make this flag irrelevant (heap too small to be practical)

The flag -XX:+CMSClassUnloadingEnabled allows GC to sweep the Perm space. It shouldn't be necessary for sbt. As you can read here the PermGen options will only pospone PermGen issues, so if you have problems with PermGen when running Jetty, just add a bigger PermGen via -XX:MaxPermSize

Geraldina