[type/__package_opkg] Do not lock execution of code-remote (revert)
Instead, rely on `nonparallel`. In any case cdist should never run explorer and code concurrently even if the dependency graph would allow to do so as it would result in many more synchronization issues than this one.
This commit is contained in:
parent
6aae58dea7
commit
3649555f35
1 changed files with 2 additions and 30 deletions
|
@ -46,34 +46,6 @@ then
|
|||
exit 0
|
||||
fi
|
||||
|
||||
cat <<'EOF'
|
||||
readonly __type_path=${__object%%${__object_id}*}
|
||||
readonly LOCKFILE="${__type_path}/cdist_opkg.lock"
|
||||
|
||||
_lock() (
|
||||
set -o noclobber
|
||||
until echo $$>"${LOCKFILE}"
|
||||
do
|
||||
while test -f "${LOCKFILE}"; do sleep 1; done
|
||||
done
|
||||
|
||||
) 2>/dev/null
|
||||
_unlock() {
|
||||
if test -s "${LOCKFILE}" && test "$(cat "${LOCKFILE}")" = $$
|
||||
then
|
||||
rm "${LOCKFILE}"
|
||||
fi
|
||||
}
|
||||
EOF
|
||||
|
||||
# NOTE: We need to lock parallel execution of code-remote to ensure that it is
|
||||
# not executed concurrently with a type explorer.
|
||||
# opkg will try to acquire the OPKG lock (usually /var/lock/opkg.lock) using
|
||||
# lockf(2) for every operation.
|
||||
# It will not wait for the lock but terminate with an error leading to an
|
||||
# incorrect outcome.
|
||||
echo 'trap _unlock EXIT'
|
||||
echo '_lock'
|
||||
|
||||
case $state_should
|
||||
in
|
||||
|
|
Loading…
Reference in a new issue