Hi @ryenus ,
the last LTS did not have real docker support, so yeah this environment variable is not available there. For 7.9.4 it would be:
docker run -it -p 9000:9000 sonarqube:7.4-community -Dsonar.path.temp=/tmp/sonarqube/
2020.09.25 05:59:34 INFO app[o.s.a.AppFileSystem] Cleaning or creating temp directory /tmp/sonarqube
2020.09.25 05:59:34 INFO app[o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2020.09.25 05:59:34 INFO app[o.s.a.p.ProcessLauncherImpl] Launch process[[key='es', ipcIndex=1, logFilenamePrefix=es]] from [/opt/sonarqube/elasticsearch]: /opt/sonarqube/elasticsearch/bin/elasticsearch -Epath.conf=/tmp/sonarqube/conf/es
2020.09.25 05:59:34 INFO app[o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
i looked into the usage of
CATALINE_HOME and for me it seems like this would only make sense if there were multiple applications using the same tomcat server, but we embed tomcat into sonarqube so there should not be another application running.
I also had a look at the thread you are referring to and what i got from this thread is that there are tests failing because sonarqube is writing into its own install directory?
Maybe i can explain the reasoning behind this:
we are currently only releasing a zip file and docker images. the zip contains everything you need in order to run sonarqube on your system except java, which makes it great for shipping to various distributions and operating systems. we also leave you the option to not use
sonar.sh/bat start but to wrap the init system of your choice around
lib/sonar-application-7.9.4.jar so you can redirect the log output somewhere else. you could even create a symlink to another location for the data that is bothering you and your filesystem supports symlinks.
all in all i would say it makes very little sense to move away from this centralized approach only because of test failures in one package managers test even thou it is stated that sonar starts anyway.
Hope i could answer your question