#!/bin/bash
#
[[ -v LOCK ]] && { kill $PPID; sleep 3; } # kill the caller
exec {var}>/tmp/lock
flock -n $var && echo was not locked || echo was locked
The subscript.sh above kills the caller (if LOCK variable is set in its environment). The subscript shows the lock is set even thereafter until the subscript finishes.
Anyway I am missing something: Even if I lock /var/lib/dpkg/lock or /var/lib/dpkg/lock-frontend this way (instead of locking /tmp/lock), that does not prevent installing a package by apt install or dpkg --install. But if I run Synaptic package manager by pkexec "/usr/sbin/synaptic", it locks the files and prevents installing by apt or dpkg from outside.
I think it can be made to work. I do not know how apt/dpkg is implemented, but I made an example by Bash:
script.sh file:
#!/bin/bash subscript. sh # edit this path
#
exec {var}>/tmp/lock
flock -n $var || { echo already locked; exit 1; }
LOCK= /path/to/
subscript.sh file:
#!/bin/bash
#
[[ -v LOCK ]] && { kill $PPID; sleep 3; } # kill the caller
exec {var}>/tmp/lock
flock -n $var && echo was not locked || echo was locked
The subscript.sh above kills the caller (if LOCK variable is set in its environment). The subscript shows the lock is set even thereafter until the subscript finishes.
Anyway I am missing something: Even if I lock /var/lib/dpkg/lock or /var/lib/ dpkg/lock- frontend this way (instead of locking /tmp/lock), that does not prevent installing a package by apt install or dpkg --install. But if I run Synaptic package manager by pkexec "/usr/sbin/ synaptic" , it locks the files and prevents installing by apt or dpkg from outside.