The startup size of the minions JVM heap is not initialized, and its value, as it turns out, is inherited instead from the startup size of midolman.
This is prone to create an error situation were the JVM is invoked with a startup value higher than the maximum.
This can lead to situations were the minions always fail to run, and eventually aborting midolman too.
which environment will be inherited?
neither of JVM_OPTS or MAX_HEAP_SIZE seems to be exported.
You are right. I was not fully aware of the problem, and it was puzzling me a little, but now you mention, I have recalled it: it happened while I was trying to add some extra JVM_OPTS to midolman container (due to an unrelated issue), so I added "ENV JVM_OPTS=whatever" and it implicitly export the variable, indirectly causing the effect described here.
So, in general, as you point, since neither JVM_OPTS or MAX_HEAP_SIZE are exported, there is no problem at all (as expected since we haven't hit this as daily basis). But it could be dangerous if JVM_OPTS is exported incidentally. Also, it seems that somehow the code in midolman-env.sh encourage it, as it include any previous content in the first use of the variable which only has effect if the variable is exported.
In summary, it was not impacting us right now (contrary to was can be inferred with the initial description in the ticket), but I think is good to add it or manage in a different way to prevent unintended usage.
i guess it's safer and simpler to clear JVM_OPTS at the top of the script. how do you think?
Yes, it would be simpler, but I don't know if this "inheritance" was requested/used by any customer to allow easy access to fine tuning the JVM.
i don't know either. but one can always edit /etc/midolman/midolman-env.sh if he wants to tune JVM options.