The rtai_shm module went away before our Hardy RTAI, so this check has
been broken for years. rtai_sched now provides the shm device file.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
This is intended to fix a race that causes occasional test failures in
the buildbot, such as this one:
http://buildbot.linuxcnc.org/buildbot-admin/builders/1502.rip-jessie-amd64/builds/161
Note that runtests ran the test called "edge/falling", which passed,
and then ran the next test, "edge/rising-starting-high", which failed,
complaining "halrun: Realtime already running."
Some background:
* Both tests are of the "test.hal" type, which get run by halrun.
* halrun first runs "realtime status" and quits if the status is True,
as it was in this failure.
* If the realtime status is False, as it normally is, halrun runs
"realtime start", then "halcmd test.hal", then "halcmd stop",
"halcmd unload all", and finally "realtime stop".
* On uspace, "realtime status" checks for the existence of a running
"rtapi_app" process.
* On uspace, "realtime stop" runs "rtapi_app exit".
The theory of this failure is this:
The "edge/falling" test finished, its halrun ran "realtime stop" which
ran "rtapi_app exit" which caused any and all rtapi_app processes to
kill themselves. But init (or whoever was the parent of rtapi_app)
had not yet gotten around to reaping the dead process, so it was still
around, in Zombie state. The "edge/rising-starting-high" test started
up, and its halrun ran "realtime status", which now returned True because
it saw the zombie rtapi_app, and the test failed.
I can replicate this failure 100% of the time by stopping init (who's the
father of the "master" rtapi_app) using "sudo gdb /sbin/init -p 1" before
the "edge/falling" test finishes, causing rtapi_app to remain a zombie.
This current commit was proposed by Jeff Epler. It does not address the
underlying race, but gives init 5 additional seconds to reap the zombie
before giving up, thus making the failure much less likely.
I have a lovely solution to the underlying race, but unfortunately
there's not enough room in this commit message to write it down.
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
/bin/readlink is supplied by the coreutils package, which is marked
"Essential: Yes" in both Hardy and Lucid. So reimplementing it in Perl
seems unnecessary (especially without a dependency on Perl).
Section 9.3.2 of the Debian Policy Manual
<http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init>
specifies the meaning of the argument to init scripts.
init scripts must accept a "force-reload" command-line argument. It does
"reload" if supported, and "restart" if not. The emc2 realtime init
script does not support reload, so "force-reload" does the same as
"restart".
Section 9.3.2 of the Debian Policy Manual
<http://www.debian.org/doc/debian-policy/ch-opersys.html#s-writing-init>
specifies the meaning of the argument to init scripts.
"reload" means "cause the configuration of the service to be reloaded
without actually stopping and restarting the service", which is not what
ours does. "reload" is optional, so I'm removing it.
compile time rather than using 'find' several times while running 'realtime
start' and 'realtime stop'. Use subsecond sleep when waiting for the shm
device to appear.
