Instead of using the '-f' parameter to start elasticsearch in the
foreground, this is now the default modus.
In order to start elasticsearch in the background, the '-d' parameter
can be used.
Closes#4392
Before, people that cloned the repo and expected to be able to run
bin/elasticsearch would be met with an awful shell error: the shell
interprets Maven variables like ${project.build.finalName} as shell
variables yet can't handle names of the form ${x.y}. This commit
explicitly checks to make sure that Maven has done its substitutions
before continuing; if Maven hasn't been run, it gives a helpful error
message.
Fixes#2954.
fix handling of non-empty JAVA_OPTS
remove usage of if/else that can be tripped by parenthesis in the variable
fixes#4127closes#4086
(cherry picked from commit fb44e9aef76026f2269f1fdc8832a44f8c76ec8f)
remove usage of if and () blocks as they clashed with user paths containing ()
postpone quotation of variables to prevent double escaping ("")
fix#3906
(cherry picked from commit 1cc095ec32a5b623f88c312f497ac5469887be97)
service.bat converts X(m(s|x)|ss) to MB/KB and uses dedicated arguments to the underlying JVM DLL
empty/unset JAVA_OPTS no longer trips commons daemon
fixes#3785
use service id for pid name
disable filtering on *.exe (caused corruption)
rename exe names and add more options to .bat
start/stop operations are now supported (and expected to be called) by service.bat
add more variables from the env to customize default behavior prior to installing the service
add manager option
fixes regarding batch flow
specify service id in description
minor readability improvement
include .exe only in ZIP archive
rename x64 service id to make it work out of the box
add elasticsearch as a service for Windows platforms
based on Apace Commons Daemon
supports both x64 and x86
Dynamic mapping allow to dynamically introduce new fields into an existing mapping. There is a (pretty rare) race condition, where a new field/object being introduced will not be immediately visible for another document that introduces it at the same time.
closes#3667, closes#3544
There is no need to write the pidfile in the bin/elasticsearchshell script
as this happens already in the java code.
Also cleaning up the bin/elasticsearch shell script a bit (no need to return
an error code when exec is called, as this forks and exits the shell script
immediately).
Closes#3529Closes#1745
Currently the bin/plugin command did not allow one to set jvm parameters
for startup. Usually this parameters are not needed (no need to configure
heap sizes for such a short running process), but one could not set the
configuration path. And that one is important for plugins in order find
out, where the plugin directory is.
This is especially problematic when elasticsearch is installed as
debian/rpm package, because the configuration file is not placed in the
same directory structure the plugin shell script is put.
This pull request allows to call bin/plugin like this
bin/plugin -Des.default.config=/etc/elasticsearch/elasticsearch.yml -install mobz/elasticsearch-head
As a last small improvement, the PluginManager now outputs the directort
the plugin was installed to in order to avoid confusion.
Closes#3304
This decision helps people who want to rollout the oracle java without having an openjdk java installed.
* Removed any hard dependency on Java in the debian package
* The debian init script does not check for an existing JAVA_HOME anymore
* Debian and RedHat initscripts now exit if they do not find a java binary (instead of starting elasticsearch in the background and swallowing the error as there is no way to log it in that case)
* Changed the debian init script to rely on the pid file instead of the argument name of process
* Added a useful error message in case no java binary is available (in elasticsearch shell script)
Closes#3304Closes#3311
It's easier to manage a configuration through environment variables than
through a config file if that config file has static values that need to
change each version (such as the ES_CLASSPATH). Trying to keep that in
Chef is tedious whereas just controlling these few settings with
environment variables like most of the other settings in here is simple
and straightforward.
Summary:
Facebook machines have on direct access to the internet. Need to tell java that we should use proxies.
Test Plan:
export JAVA_OPTS="-Dhttp.proxyHost=<ip> -Dhttp.proxyPort=8080"