This message was deleted.

Such "disappeared unexpectedly" are usually as the error suggests cases where the daemon was killed or crashed. Because of that you usually do also not find anything useful in the daemon log that could explain it. The only instances where I have seen this happening so far, were indeed the Linux OOM killer that thought it should kill the process, for example because RAM was low, or the Daemon requested more RAM as was assigned to a Docker container as Java used to calculate the available RAM wrongly (from the host system, not the container). You would find such incidents in the OS logs instead that tell you that it killed process X for reason Y.

Right, tricky since the pod is deleted once the command is finished and the container logs will not contain what I need. But thanks, I'll see what I can find in that area.

Nope, sorry. If the CI environment kills the daemon you have to investigate with the CI.

To make it even funnier, adding --debug to the daemon makes it finish correctly and not disappearing :/

...

It looks like a bug in the daemon, but it is hard to say. More likely a bug in a 3pp plugin I assume. Spotless is a possible culprit in that case since that plugin reports a build error when I use --debug. In that case, allowing a plugin to crash the daemon is not good either. Memory looks quite OK, performance tab in the scan says: G1 Old Gen 278.5 MiB/4 GiB (6.8%)

Well any plugin could theoretically do

System.exit(0)

or doing something to crash the JVM. Nothing Gradle could really do about that. (Yes, I know

System.exit

could be prevented with a security manager, but a plugin should just not do that :-D)

true, true

Exit hooks are never guaranteed to run. They should only be used for fallback cleanup stuff, but never for important work. If the JVM is killed, they are not run. If the JVM crashes, they are not run. If one of the hooks needs too much time it is aborted and all pending hooks do not run. ...

Hi Joachim, It’s good you found a way to stabilise your CI. If the Spotbugs tasks should not run in parallel then the Spotbugs plugin should take care of that. Care to raise an issue to them? By the way, you can use Gradle features to influence the parallelism of tasks. You can declare that a set of task cannot run in parallel by registering a “shared build service” that does nothing but is registered to the tasks you want to affect, and set its

maxParallelUsages

to 1. That’s exactly what the Spotbugs plugin should do if its tasks can’t run in parallel, you can do that in your build so that you don’t have to split the execution and use

--no-parallel

which affects all tasks.

The Spotbugs execution used to be problematic in the past due to static state used by Spotbugs and so even different projects built by the same daemon influenced each other. But this is long fixed already. The plugin now (by default) uses a no-isolation worker for parallelism from which it uses

javaExec

for necessary isolation. It can of course happen that you run out of RAM, especially when running many of them concurrently. But other than that I think the SpotBugs plugin should now be pretty safe for parallel execution.

Are you using the latest Spotbugs Joachim?

No @Paul Merlin we are one main version behind in one of our older branches.

Ok. I have no idea when that plugin got stable when running in parallel. It might be worth it to upgrade.

If you cannot update, which version exactly is "one main version behind"? There was a time where it used process-isolated worker by default which was not good but had a property to use javaexec instead. With 4.7.0 the hybrid approach, using no-isolation worker for parallelity and in that javaexec for proper isolation was added but was not yet the default, but could be enabled via property. The hybrid worker is used by default since 5.0.0.

We will look into upgrading, seems like the best way forward. Thanks