Elasticsearch: "thread stack size not set" on Elasticsearch-5.0.0-alpha2 Windows

[anhlqn]

Elasticsearch version: 5.0.0-alpha2

JVM version: jre1.8.0_91

OS version: Windows 10

Description of the problem including expected versus actual behavior:
When installing ES service on Windows, I received the following error

thread stack size not set; configure via "E:\ELK\elasticsearch-5.0.0-alpha2\config\jvm.options" or ES_JAVA_OPTS"

I think -Xss256k or an optimal setting should exist in jvm.options by default

Steps to reproduce:

1. Run service.bat install

Provide logs (if relevant):

[jasontedor]

This is a deliberate choice. On all systems except for running Elasticsearch as a service on Windows, the thread stack size setting is not needed and we can pick up the JVM defaults. The issue when running Elasticsearch as a service on Windows is that procrun requires min heap, max heap and thread stack size to be set. Thus, we ship with out-of-the-box settings that work for all cases except running Windows as a service. We use to set this in the service installer, but the issue there is that moves a piece of the JVM configuration out of the jvm.options file negating the point of the introduction of that configuration file.

[jasontedor]

Thank you for reporting. While it was a deliberate choice, we should definitely communicate this situation better and your report prompted me to open #18324 to add a note to the documentation regarding this. There is an effort to have dedicated Windows packaging which will alleviate this issue but I can not give a timeframe for when that effort will be completed.

@clintongormley added you to the Pioneer Program. Thanks again!

[anhlqn]

Thanks, it would be helpful for new users of ES on windows as I don't see many documents on forum or Google about how to set a thread stack size for ES. I guess because it used to be set by default.

[kellihall]

I agree. I'm trying to install it as a service on Windows (as I did with earlier ES versions), but getting error message noted above. Please be sure to document this issue and how to resolve.

Thanks!

• Kelli

[jasontedor]

@kellihall It was documented in #18324 and is currently available in the Installing Elasticsearch as a Service on Windows section of the docs. :smile:

[kellihall]

That worked! I added -Xss1m to the jvm.options file in the config folder and re-ran the 'service.bat install' command. It is now installed and running as a service in windows.
Thanks so much!!

[jasontedor]

@kellihall You're very welcome.

[niemyjski]

I got this error on the rtm, as a long time user of elastic I know all the commands so I wouldn't read the docs. The error message lead me to the jvm.options... However, there is no mention of this. This setting should be talked about at the top of the file so those looking at the file know what to do without googling, finding this issue and then reading the install docs and finding a note (one of many) mentioning this.

[nik9000]

finding this issue and then reading the install docs and finding a note (one of many) mentioning this.

If you open a PR to put the information in the file I'd be happy to merge it. I'm not really sure what to do about the other notes though. Ultimately we have to document breaking changes in one place and that is the breaking changes page. I'm happy to brainstorm better ways to get eyes to that page though.

[jasontedor]

This setting should be talked about at the top of the file so those looking at the file know what to do without googling, finding this issue and then reading the install docs and finding a note (one of many) mentioning this.

I don't agree as this is specific to the Windows service only. Perhaps the error message should be changed to be more explicit though.

[Smoothfu]

Open the file,\elasticsearch-5.0.0\elasticsearch-5.0.0\config\jvm.options, add -Xsslm after
-Xms2g -Xmx2g
then save and run elasticsearch-service.bat again and it has been installed.Copy from http://blog.csdn.net/leo063/article/details/52994786

[niemyjski]

So what is the census here? Should I open a pr or the error message be improved. This definitely isn't a good on boarding process on windows. Could this setting be inferred when running on windows?

[jasontedor]

@niemyjski I integrated #21200 and #21201 already. The change to the script to provide a more helpful error message will be included in the 5.0.1 patch release, and the doc update is live as of some time yesterday.

[jasontedor]

@Smoothfu It doesn't have to go below the -Xms and -Xmx, it can go on any otherwise line in the file and on 64-bit Windows it should be -Xss1m not -Xsslm as you have.

[Smoothfu]

@jasontedor ,it may be wrong, This morning when I start the elasticsearch.failed and it showed that
"Invalid thread stack size:-Xsslm
Error:Could not create the Java Virtual Machine.
Error:A fatal exception has occured.Program will exit." So I erase the _Xsslm in the cinfig file,save,start,OK.

18317 occured when elasticsearch-service.bat install ,it would be server.But from the client side,it doesn't need _Xsslm.

I'm a .net programmer,not familiar with Java including JVM

[anhlqn]

How about putting some recommended values for -Xss inside the java.options file by default?

-Xmx1g
# 64-bit Windows stack size
#-Xss1m

# 32-bit Windows stack size
#-Xss320k

Is there an assumption that not many people run production ES (meaning running ES as a service) on Windows?

[jasontedor]

@Smoothfu It's a 1 (one) not an l (ell).

[jasontedor]

How about putting some recommended values for -Xss inside the java.options file by default?

I'm opposed to this because it's OS specific, I'm hoping that the improved docs are sufficient here.

Is there an assumption that not many people run production ES (meaning running ES as a service) on Windows?

It's not an assumption, we know that this user base is not large.

[gmarz]

I agree this isn't the best experience on Windows, and also caught me by surprise. I think the service should just work out of the box.

Since it's Windows specific, can we not just supply a default value in the service bat itself instead of jvm.options?

[jasontedor]

@gmarz I don't think we should, because then it's moving JVM configuration out of the jvm.options file.

[gmarz]

True, but I think there's a valid argument here for treating Xss as a special case since it's OS specific. We'd still give precedence to Xss in the jvm.options file, and only fallback to a default (provided in the script) if it isn't present.

Keep in mind, procrun already moves configuration out of the jvm.options file by storing the JVM options in the Windows registry after installing, which is exposed via the manager UI.

[jasontedor]

True, but I think there's a valid argument here for treating Xss as a special case since it's OS specific. We'd still give precedence to Xss in the jvm.options file, and only fallback to a default (provided in the script) if it isn't present.

I'm unconvinced, there are other OS-specific settings for which the same argument could be made.

Keep in mind, procrun already moves configuration out of the jvm.options file by storing the JVM options in the Windows registry after installing, which is exposed via the manager UI.

Yes, but it's configured by reading jvm.options.

It's terrible that procrun requires this, and doesn't just rely on JVM defaults.

[niemyjski]

I agree with @gmarz.. please keep in mind a large share of prod users won't be using windows but I'm betting a ton of developers are running elastic as a service on windows. Do you have stats for this? This should just work on windows I mean you setup guide has always inferred juts launch the batch file...

[gmarz]

I'm unconvinced, there are other OS-specific settings for which the same argument could be made.

Well, it's really procrun specific.

Yes, but it's configured by reading jvm.options.

I guess my point is if the argument against a default value in the bat file is that there should be a single source of truth for JVM options (e.g. the jvm.options file), then it's not a strong one because of the simple the fact that procrun uses the registry after it's installed, and thus it's configuration and jvm.options are already prone to diverging.

It's terrible that procrun requires this, and doesn't just rely on JVM defaults.

Agreed :/. I'm also ok with just improving the docs, but I think a default value in the service.bat would be pragmatic. I'd be happy to open a PR.

[jasontedor]

I opened #21920.