Contexto:
Deseja bloquear a atividade do etckeeper/apt hook durante o backup especial.
O objetivo é preservar a integridade do pacote inteiro, por exemplo, esperar até que a instalação de qualquer pacote seja concluída e impedir que uma nova instalação seja iniciada até que o backup especial seja concluído.
Shell script encontrado no cron que parece estar tentando bloquear
/var/cache/etckeeper/packagelist.pre-install
mas na verdade não é executado atomicamente e por isso é falho. Presumo que o cron shell script faça parte da instalação do Ubuntu 16.04 , não do lançamento do etckeeper . Código de bloqueio defeituoso mostrado abaixo.
Pesquisou a documentação do etckeeper sobre o uso de /var/cache/etckeeper/packagelist.pre-install
um arquivo de bloqueio. Nenhuma documentação encontrada. Mas encontrei um pedaço de arquivo de script que grava /var/cache/etckeeper/packagelist.pre-install
sem tratá-lo como um arquivo de bloqueio. Neste momento, estou presumindo que /var/cache/etckeeper/packagelist.pre-install
não se destina a servir como uma interface de arquivo de bloqueio para o etckeeper . Script interno do Etckeeper não tratando
/var/cache/etckeeper/packagelist.pre-install
como um arquivo de bloqueio mostrado abaixo.
Pergunta 1: Existe (e em caso afirmativo onde está) documentação sobre o mecanismo de bloqueio do etckeeper ou um portal de desenvolvedores para emitir um pedido de esclarecimento?
Há muitas perguntas e muita discussão nos sites stackexchange sobre o uso de
/var/lib/apt/lists/lock (we call it apt lock below)
e
/var/lib/dpkg/lock (we call it dpkg lock below)
como bloqueios para apt e dpkg , respectivamente. Todas as comunicações dizem respeito a fechaduras emperradas, como diagnosticá-las e como destravá-las. No entanto, não encontro referências à documentação oficial do apt e dpkg especificando o uso desses arquivos de bloqueio como uma interface formal.
Pergunta 2: Existe (e em caso afirmativo onde está) documentação sobre o mecanismo de bloqueio do apt e/ou mecanismo de bloqueio do dpkg como interfaces públicas?
Script de shell de tentativa de bloqueio com falha, provavelmente fornecido pelo Ubuntu 16.04 :
$ sudo cat /etc/cron.daily/etckeeper
#!/bin/sh
set -e
if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
. /etc/etckeeper/etckeeper.conf
if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
# avoid autocommit if an install run is in progress
lockfile=/var/cache/etckeeper/packagelist.pre-install
if [ -e "$lockfile" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
rm -f "$lockfile" # stale
fi
if [ ! -e "$lockfile" ]; then
AVOID_SPECIAL_FILE_WARNING=1
export AVOID_SPECIAL_FILE_WARNING
if etckeeper unclean; then
etckeeper commit "daily autocommit" >/dev/null
fi
fi
fi
fi
Etckeeper shell scipt interno escrevendo packagelist.pre-install
e não tratando-o como um bloqueio - portanto, não acho que tenha sido planejado como uma interface de bloqueio.
$ sudo cat /etc/etckeeper/pre-install.d/10packagelist
#!/bin/sh
# This list will be later used when committing.
mkdir -p /var/cache/etckeeper/
etckeeper list-installed > /var/cache/etckeeper/packagelist.pre-install
etckeeper list-installed fmt > /var/cache/etckeeper/packagelist.fmt
O cron job está tratando
/var/cache/etckeeper/packagelist.pre-install
como evidência de que uma instalação está sendo processada, portanto, não deve arquivar nada ainda. Esse arquivo não deveria ser um arquivo de bloqueio, mas o cron job o está usando como um substituto.No entanto, eu particularmente não me preocuparia com
etckeeper
nenhum arquivo de bloqueio que ele tenha ou não. Se você deseja um backup consistente de umaetckeeper
árvore gerenciada, use os recursos do VCS (mas não se esqueça dos arquivos ignorados).Os
dpkg
bloqueios são documentados (embora brevemente) como interfaces públicas emfrontend.txt
(/usr/share/doc/dpkg-dev/frontend.txt
indpkg-dev
).