Whenever we allow concurrent processes to share a resource, we open ourselves up the possibilty of deadlock. This is a situation where two or more processes are locked in a vicious stalemate from which none can escape. Another problem is that it might be possible to start an infinite loop: cfengine starts itself.
Cfengine protects you from such loops to a large
degree. It should not be possible to make such a loop by accident.
The reason for this is the locking mechanism which prevents tasks
being repeated too often. If you start a cfengine process which
contains a shell-command to start cfengine again, this shell
command will be locked, so it will not be possible to run it
a second time. So while you might be able to start a second
cfengine process, further processes will not be started and
you will simply have wasted a little CPU time. When the first
cfengine returns, the tasks which the second cfengine completed
will not be repeated unless you have set the IfElapsed time
or the ExpireAfter time to zero.
In general, if you wish to avoid problems like this, you
should not disable the locking mechanism by setting these two
times to zero.
The possibility of deadlock arises in network connection. Cfengine will
not attempt to use the network to copy a file which can be copied
internally from some machine to itself. It will always replace the
server= directive in a copy with `localhost' to avoid unnecessary
network connections.
The prevents one kind of deadlock which could occur: namely cfrun
executes cfengine on host A (cfd on host A is then blocked until this
completes), but the host A configuration file contains a remote copy
from itself to itself. This remote copy would then have to wait for cfd
to unblock, but this would be impossible since cfd cannot unblock until
it has the file. By avoiding remote copies to localhost, this possibility
is avoided.
Go to the first, previous, next, last section, table of contents.