question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

java.io.IOException: Could not start process: <EOF>

See original GitHub issue

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.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:2
  • Comments:26 (7 by maintainers)

github_iconTop GitHub Comments

4reactions
mainedufresnecommented, Jul 10, 2017

I figured it out. The following worked for me in my Dockerfile:

WORKDIR /build-env
ADD . /build-env
RUN apk update &&  apk add bash && apk add libstdc++
ENV LC_ALL=C
RUN ./gradlew build```
4reactions
magiccraftercommented, Nov 29, 2016

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

flapdoodle can't start mongo ( Could not start process: <EOF>)
Caused by: java.io.IOException: Could not start process: at de.flapdoodle.embed.mongo.AbstractMongoProcess.
Read more >
Why does my flapdoodle Embedded MongoDB test fail to run ...
in ; is java.io.IOException: Could not start process: <EOF> at de.flapdoodle.embed.mongo.AbstractMongoProcess.onAfterProcessStart( ...
Read more >
java.io.IOException: Could not start process: <EOF>
While compiling tests cases getting exception Caused by: java.io.IOException: Could not start process:
Read more >
Meme Overflow on Twitter: "Why does my flapdoodle ...
Why does my flapdoodle Embedded MongoDB test fail to run? (creating 'embeddedMongoServer' could not start process EOF) ...
Read more >
de.flapdoodle.embed.mongo.MongodExecutable.start java ...
isConfigServer()) { throw new Exception( "Mongo configuration is not a ... (final IOException e) { throw new IllegalStateException("Failed to start MongoDB!
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found