Problem with tmp and wrapper java parameters

[Anonymous]

Hi,

I am using the wrapper on Redhat Linux and have a problem with its use of /tmp. The configuration I have (which I can't change) has the noexec flag set on the /tmp mount. This causes the wrapper scripts (such as start/stop) to fail with:

java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.rzo.yajsw.boot.WrapperExeBooter.main(WrapperExeBooter.java:35)
Caused by: java.lang.UnsatisfiedLinkError: /tmp/jna9111935027002423967.tmp: /tmp/jna9111935027002423967.tmp: failed to map segment from shared object: Operation not permitted

I can work around this setting the Java parameter -Djava.io.tmpdir to a different directory - but this needs to be in the wrapper startup (not my app startup). When running as a service, I can't find a way to pass a Java property into the wrapper Java startup.

I thought I could achive this by using the following:

wrapper.ntservice.additional.1=-Djava.io.tmpdir=/data/tmp

But this seems to be ignored (is it Windows only)?

Is there some other way to specify a Java option which will get used in the 'start' command of the service?

Thanks,
Jon

[Anonymous]

I found a workaround for this - setting the following environment variable:

export _JAVA_OPTIONS=-Djava.io.tmpdir=/data/tmp

I'd be interested to know if this is the "recommended" approach.

Thanks,
Jon

[rzo]

Hello,

thanks for pointing this out.

concerning temp folder:

the temp folder is used in yajsw for:

1. cyclic buffers (files) for input/output streams
2. for jna native library file

NOTE: all these files are created each time the wrapper is invoked. there has been issues deleting these files, so they are currently left in the temp folder, and if you restart your application often, you will have to take care of purging the temp folder from time to time.

to 1:
per default the temp folder is taken from the java property: java.io.tmpdir
or from the configuration property: wrapper.tmp.path, if defined.

to 2:
The file is created by calling File.createTempFile()
see http://download.oracle.com/javase/1.4.2/docs/api/java/io/File.html#createTempFile%28java.lang.String,%20java.lang.String,%20java.io.File%29

using export _JAVA_OPTIONS as you suggest is currently the best option. although it is not perfect.

my long term intention was that the configuration property wrapper.tmp.path should be used for all cases.
i have not looked into this since this did not seem to be an issue.

i will try to get this done for the next release.

• Ron

[Anonymous]

Thanks - that makes sense, it will be the JNI library causing the problem with 'noexec' then.

The wrapper.tmp.path sounds like a good long term solution, I'll just use my workaround for now.

Thanks, Jon