[OpenIndiana-discuss] shell script mutex locking or process signaling

[Cedric Blancher]

On 30 May 2013 16:15, Edward Ned Harvey (openindiana)
<openindiana at nedharvey.com> wrote:
> Here's the problem I'm trying to solve:  SMF service is configured to launch things like VirtualBox during startup / shutdown.  This startup process can take a long time (10, 20 minutes) so if there's a problem of any kind for any reason, you might do things like enable and disable or refresh the service ... but each time the script gets launched, it's not aware of the previous one.  I'm really looking for a good way to allow multiple instances of some shell script to signal each other.  Let the earlier instances die and the later instances take over control.

1. There are realtime signals which support 'payload' values, either a
long or void* value. ksh93v- added support for this at the shell
script level:
ksh -c 'trap "print \"child pid=\${.sh.sig.pid}\"
msg=\${.sh.sig.value}\"" RTMIN ; ((pid=$$)); ( for i in a b c d e f ;
do kill -q $((16#$i)) -RTMIN $pid ;done) & while ! wait ; do true ;
done ; true'
child pid=36012 msg=16#a
child pid=36012 msg=16#b
child pid=36012 msg=16#c
child pid=36012 msg=16#d
child pid=36012 msg=16#e
child pid=36012 msg=16#f

Unlike normal signals POSIX realtime signals are guaranteed to be
reliable, i.e. they can't get lost. Care has to be taken that the
underlying system passes the POSIX realtime tests - when the feature
was first implemented it triggered a flurry of bug reports in AIX.
Realtime signals are also be known to be buggy on Solaris prior the
fix for #6820737 (does Illumos contain that changeset?) landed.

2. Roland Mainz once wrote code implementing a class (ksh calls this
'types') which implements shared and exclusive locks and synchronized
sections for shell scripts:
http://svn.nrubsig.org/svn/people/gisburn/scripts/filemutexdemo1.sh

3. There is always the option of implementing a ksh builtin around
lockf(3). This works as long you're using it on a local file system or
NFSv4. Using it with NFSv3 will put you on the mercy of whoever tacked
locking on top of that implementation. Using smbfs will, well, either
work, hang the box or hang the process with subsequent panic depending
on OS if you kill -KILL the hanging process.

4. mutex on mmap() memory. Fast, but the locks only work on the local
machine. No, NetApps NFS extensions for atomic CAS won't help.

Ced
-- 
Cedric Blancher <cedric.blancher at googlemail.com>
Institute Pasteur