de.flapdoodle.embed.mongo: java.io.IOException: Could not start process:
I’m only seeing this error on our CI machine, a SLES 10.2 box (kernel version 2.6.16.60-0.21-smp). I get the error both running through Jenkins and from a workspace I cloned on that machine to try to debug. The same code runs fine on my Mac, my co-workers Mac, and elsewhere on a OLE 6.3.1 box (kernel version 2.6.32-279.11.1.el6.x86_64). Here’s the exception:
java.io.IOException: Could not start process: <EOF>
at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart(AbstractMongoProcess.java:79) ~[de.flapdoodle.embed.mongo-1.50.5.jar:na]
at de.flapdoodle.embed.process.runtime.AbstractProcess.<init>(AbstractProcess.java:114) ~[de.flapdoodle.embed.process-1.50.2.jar:na]
at de.flapdoodle.embed.mongo.AbstractMongoProcess.<init>(AbstractMongoProcess.java:53) ~[de.flapdoodle.embed.mongo-1.50.5.jar:na]
at de.flapdoodle.embed.mongo.MongodProcess.<init>(MongodProcess.java:50) ~[de.flapdoodle.embed.mongo-1.50.5.jar:na]
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:44) ~[de.flapdoodle.embed.mongo-1.50.5.jar:na]
at de.flapdoodle.embed.mongo.MongodExecutable.start(MongodExecutable.java:34) ~[de.flapdoodle.embed.mongo-1.50.5.jar:na]
at de.flapdoodle.embed.process.runtime.Executable.start(Executable.java:101) ~[de.flapdoodle.embed.process-1.50.2.jar:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_25]
at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0_25]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1706) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1645) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574) ~[spring-beans-4.2.4.RELEASE.jar:4.2.4.RELEASE]
...
This is a Spring Boot application, that makes heavy use of auto-configuration, but I’m specifying the IRuntimeConfig like so, because I need to provide the proxy info:
@Primary
@Bean
IRuntimeConfig runtimeConfig()
{
final Command command = Command.MongoD;
return new RuntimeConfigBuilder()
.defaults(command)
.artifactStore(new ExtractedArtifactStoreBuilder()
.defaults(command)
.download(new DownloadConfigBuilder()
.defaultsForCommand(command)
.proxyFactory(new HttpProxyFactory("proxy.employer.com", 80))
.build()))
.build();
}
I’ve tried the workaround mentioned on another ticket of setting LC_ALL=C, to no avail. Let me know if there’s any additional information I should gather.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 2
- Comments: 26 (7 by maintainers)
This problem happens only if your environment is configured to run on 32bit java. Try running with 64bit java and the issue should disappear. Short explanations is that during mongod initialization, based on the java platform, the embedded-mongo will decide which mongod build to use. For the 32bit monogod build, the default “wiredTiger” storage engine is not available and the process could not start.
I figured it out. The following worked for me in my Dockerfile:
Setting locale fixed my problem.
http://stackoverflow.com/questions/26337557/badvalue-invalid-or-no-user-locale-set-please-ensure-lang-and-or-lc-environme
I’ve gotten this multiple times when mongo gets corrupted (through various means). The easiest way to find the root cause is to start up mongo again in whatever directory it was started before. You’ll see real error messages come out. It would be helpful if, upon finding EOF, the entire mongo log was printed to the console.
The problem on Windows seems to be related to MongoDB 3.6.0, running the extracted mongod executable in
%USERPROFILE%\.embedmongo\extracted\Windows-B64--3.6.0
abruptly ends cause the mongod process fails to locatelibeay32.dll
andssleay32.dll
. Throwing the ddls into the extract folder does not seem to work either. Running the same with MongoDB 3.4.1 works fine.Having said that, MongoDB 3.6.0 does not run on RHEL either out of the box or with any of the locale hacks from above.