MAJ pour virer automatiquement db.lck

Bonjour à tous. :salut:

Sans que je ne sache pourquoi, le célèbre verrou /var/lib/pacman/db.lck reste après qu'une instance de pacman se soit terminée.
Rien de bien méchant , mais c'est assez pénible de devoir fréquemment virer ce verrou.
Il y a déjà des propositions de scripts intéressants notamment avec zenity qui ont été proposés.
Je me suis amusé a en faire un on ne peut plus simple qui fonctionne que j'ai nommé "MAJ" pour le différencier de l'alias "maj" .
On crée un fichier texte dans le home nommé MAJ, on y colle ceci et on sauvegarde:

#!/bin/bash

if [[ ! $(whoami) = "root" ]]; then
echo "Ce script doit être lancé avec les droits root."
exit 1
fi
cd /var/lib/pacman/
rm db.lck
echo "Le verrou db.lck a été supprimé"
cd 
pacman-mirrors -g -c France,Germany,Netherlands,United_Kingdom
pacman -Syyu
exit 0

Ensuite on lui donne les droits exécutifs et on le déplace dans /usr/local/bin/ qui est dédié aux programmes locaux avec un petit :

sudo chmod a+x MAJ
mv MAJ /usr/local/bin/

(Notez qu'on peut le laisser dans le home ,mais il faudra alors le lancer avec sudo ./MAJ)
Il n' y a plus qu' a taper

sudo MAJ

et tout se fait automatiquement avec ou sans verrou. Si le verrou est absent il y a :

rm: impossible de supprimer « db.lck »: Aucun fichier ou dossier de ce type
Le verrou db.lck a été supprimé

Bien sur, ce script manque d'élégance et peut être amélioré , mais ça le fait :

[steph@manjaro ~]$ sudo MAJ
[sudo] password for steph: 
 Le verrou db.lck a été supprimé
:: Synchronisation des bases de données de paquets...
 core                     134,4 KiB   187K/s 00:01 [------------] 100%
 extra                   1858,6 KiB   185K/s 00:10 [------------] 100%
 community                  2,9 MiB   184K/s 00:16 [------------] 100%
 multilib                 161,5 KiB   186K/s 00:01 [------------] 100%
:: Début de la mise à jour complète du système...
 il n’y a rien à faire

Pour info, j'ai fais des tests avec un fichier texte "db.lck" contenant un truc du genre "fqzd" et ça suffit pour bloquer la mise à jour .

lemust83 a écrit :Sans que je ne sache pourquoi, le célèbre verrou /var/lib/pacman/db.lck reste après qu'une instance de pacman se soit terminée.
Rien de bien méchant , mais c'est assez pénible de devoir fréquemment virer ce verrou.

Salut St****** :bjr:

Je ne sais pas comment tu arrives à avoir ça aussi souvent ! Perso, je crois que ça m'est arrivé une fois en 2012, et puis plus jamais.

Je signale que dans le .bashrc il existe un alias fixit fait pour ça.

alias fixit='sudo rm -f /var/lib/pacman/db.lck && sudo pacman-mirrors -g && sudo pacman -Syyuu && sudo pacman -Suu'

Ce que je ne comprend pas , c'est pourquoi je ne peux que le faire qu' en m'y rendant en root (su -) .
Si je fais comme dans un alias

sudo rm /var/lib/pacman/db.lck
rm: impossible de supprimer « db.lck »: Aucun fichier ou dossier de ce type

De même si je le fais en root

su -
rm /var/lib/pacman/db.lck
rm: impossible de supprimer « db.lck»: Aucun fichier ou dossier de ce type

Par contre si je fais:

su -
cd /var/lib/pacman/
rm db.lck

Là ça marche, d'où l'idée de ce script.
Il semblerait que pamac, même si on ne l'utilise pas soit le responsable.

Vire ce pamac de m :censure:

. Préfère-lui octopi :bien

lemust83 a écrit :Si je fais comme dans un alias
sudo rm /var/lib/pacman/db.lck
rm: impossible de supprimer « db.lck »: Aucun fichier ou dossier de ce type
.

ce fichier est généré par pacman a chaque fois qu'il est lancé ; il bloque automatiquement une autre instance histoire de ne pas se retrouver avec 2 opérations contradictoires en même temps.

pamac et optopi utilisent pacman donc oui parfois, très rarement, il peut avoir un blocage.

si je désire en provoquer un :

yaourt -Syu &; ls /var/lib/pacman/ &; yaourt -Syu ; ls -l /var/lib/pacman/

le fichier db.lck n'a eu qu'une durée de vie d'une seconde (meme pas vu avec le ls)! normalement le temps de taper la commande de suppression c'est fini

ici, Ton erreur "rm" indique clairement que le fichier lock n'existe plus ce qui me parait être normal !

pour faire une véritable erreur plus longue/testable: "sudo pacman -S git &; ls /var/lib/pacman" ici pacman est bloqué à vie en attente d'une réponse clavier(o/n). ici tu as un méchant lock pour tester ta commande sudo rm ... ou ton script
ps : je retrouve mon processus par ps -aux | grep "pacman -S git" et le kill
ps2: sinon ouvrir 2 terminals fonctionne aussi très bien : un bloqué sur la question (0/n) et l'autre pour les tests...

J'ai indiqué l'erreur

rm: impossible de supprimer « db.lck »: Aucun fichier ou dossier de ce type

dans le seul but de démontrer que le script est capable de poursuivre la mise à jour avec ou sans verrou.
J'aimerais surtout comprendre pourquoi ce db.lck persiste alors que sa durée de "vie" ne devrait être que du temps de l'instance de pacman.
Ce script n'est en fait qu'un pisalé à un petit bug probablement causé par pamac et qui peut permettre à des amis de tux entres autres de ne plus le solliciter sans cesse à ce propos :gsourire:

J'ai fait le test donné par papajoke et envoyé l'alias, résultat = OK.

Sur la manjaro-xfce toute fraîche, j'ouvre le gestionnaire de paramètres manjaro, et je demande à installer les paquets linguistiques > il me sort le truc du db.lck.
Je rajoute l'alias fixit dans le .bashrc et j'envoie la commande => nickel.

Perso, je n'ai eu le problème qu'en essayant Pamac, mais comme je ne l'utilise qu'en notificateur de mise à jour, le db.lck n'est jamais réapparu.

Sauf quand j'ai arrêté une installation avec CTRL+C, je n'ai jamais eu de problème de db.lck