Why does my startup of MDCE services on Linux hang?

Under some circumstances, a call to

./mdce console

takes several minutes to start the activation service. Sometimes it hangs indefinitely. The JVM is started correctly by the Java Service Wrapper, but it appears that nothing beyond that is paying attention. One might almost believe that there is a network configuration issue with DNS, or some other slow socket type problem.

Answer 1

[MathWorks Support Team]

This problem was observed on a Red Hat Enterprise Workstation 3 machine, but is probably endemic to newer Red Hat distributions. The cause is a lack of random information from /dev/random. It appears that in starting the JINI services needed by MDCE, Java implicitly makes use of this source of random information. However, this random information is gathered from random activity on the machine, such as mouse movement, keyboard usage, disk operation, and other such normally occurring events. If the machine is a server with no attached keyboard and mouse, without a high amount of disk activity, then /dev/random ceases to provide any information, and a call to read on the device blocks indefinitely, as we observe. There are a number of mechanisms to diagnose this problem:

1. Check how much random information comes out of /dev/random. At a shell prompt, type

cat /dev/random | od

If this produces a continuous, slow, stream of information, then things are normal. However, if some random information appears and then it blocks, it is likely that MDCE will not work properly.

2. Attempt to generate extra random information. One mechanism for getting random data is disk access. Thus, you can increase the rate of random information production by undertaking tasks of intensive disk access. For example, you can search the entire disk for some particular file:

find / -name someRandomFileName

If the MDCE process is hung and a command similar to the one above gets it going, then you are probably experiencing this problem. This problem is caused by a known characteristic in some Linux kernels (see

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117218).

There are a couple possible solutions to this problem. The most obvious is to ensure adequate usage of the server so that the random entropy pool does not become exhausted. However, that is not always possible, so the best current workaround is to change the implementation of /dev/random from a cryptographically secure source to a pseudorandom source (as used in /dev/urandom). You can do this by using

rm /dev/random

mknod -m 0444 /dev/random c 1 9

(See Linux random notes:

https://www.lifewire.com/how-to-redirect-command-output-to-a-file-2618084

)