Vous n'êtes pas identifié(e).
les fichiers "lock" sont du 15 janvier 2016
-rw-r----- 1 root root 0 janv. 15 2016 lock
En soit, ce n'est pas l'existence du fichier qui est le verrou. Le fichier existe juste
pour poser un verrou en écriture dessus, bien qu'on écrive jamais rien dedans.
C'est un appel système qui permet de poser ce genre de verrou. Si un verrou est déjà posé
l'appel échoue. Il existe plusieurs techniques de verrouillage, ici c'est une méthode coopérative
qui est utilisée. Cela veut dire que ça n'empêche pas d'écrire dans le fichier verrouillé (bien
qu'ici on n'écrira jamais dans le fichier lock).
L'autre méthode plus rarement utilisée est celle des verrous obligatoires (? je me souviens plus
du nom exact) pour lesquels il faut une option de montage du système de fichier particulière (mandatory).
Dans ce cas l'écriture sur un fichier verrouillé provoque une erreur, il faut obligatoirement obtenir
le verrou en écriture pour écrire dans le fichier (sauf si le fichier n'était pas verrouillé, ce qui pose pas mal
de problèmes avec les applications qui ne respectent pas les règles si je me souviens bien…)
Pour couronner le tout, il existe deux appels systèmes pour poser des verrous flock(2) et une fonction
appeler de fcntl(2) qui sert à d'autres choses particulières… Et bien entendu ces deux appels posent
des verrous de type différents, il faut que les applications qui veulent coopérer utilisent la même méthode !
Voilà, donc inutile de prendre en compte la date de ce fichier qui est créé quand il n'existe pas et
laissé comme cela.
Dernière modification par enicar (22-07-2017 09:51:34)
Hors ligne
Pour la liste des paquets installés (arrêté moi si je me trompe)
Le retour affiche bien :
Hors ligne
histoire de voir si tout va bien
regarde si tu n'utilises pas aptitude et apt en même temps, voir avec ps si l'un est pas fermé
vu sur le net ceci
Dernière modification par lagrenouille (22-07-2017 11:18:53)
site de mon association 1901
https://le-caillou.le-pic.org
Hors ligne
me renvoie :
Cela me fait penser que j'ai essayé d'installer jitsi via dpkg, et que ça avait foiré...
Hors ligne
site de mon association 1901
https://le-caillou.le-pic.org
Hors ligne
rc veut dire que tu l'as viré et mal purgédpkg --purge jitsi-meet
Merci pour l'explication, purge faite.
Hors ligne
me renvoie :
Hors ligne
pour un truc spécifique, exemple ssh
pour ça j'ai dit une connerie, c'est en root et pas en user
Dernière modification par lagrenouille (22-07-2017 12:48:34)
site de mon association 1901
https://le-caillou.le-pic.org
Hors ligne
pour lister les processus dont le nom est exactement « apt ».
Sinon, on peut utiliser pgrep qui renvoie juste les numéros de processus (pid) concernés :
pour lister tous les pid dont le nom de commande contient la chaîne « apt ».
Mais pour tester si un fichier est verrouiller avec flock on peut utiliser la commande
du même nom :
La même que précédemment sous forme de script (à copier dans un
fichier appelé test-lock.sh par exemple et à exécuter en tant que
root) :
Je pense qu'il utilise flock pour le verrou car c'est plus simple à
mettre en œuvre…
Le test de verrouillage ne fonctionne pas ! dommage… et puis ce n'est pas
comme cela qu'on se sert de flock
Dernière modification par enicar (22-07-2017 13:43:59)
Hors ligne
un apt-get update doit donner ceci
tu parle de plusieurs OS sur cette machine , pas de mélange ? , partitions commune ?
en simulation que donne
retour
tenter de supprimer "aptitude" , "unattended-upgrade" , avec une purge , facile ensuite a remettre en service (pour enlever le doute sur l utilisation de services non voulue)
je connais pas KDE , mais ça reste une debian pour la gestion d apt .
@enicar
merci pour l' explication
il faut retenir que le contenu de lock est nul , et que en cas d' absence il sera recréé ( la date de création aucune importance )
nota : il y a un espèce de drapeau sur le fichier "lock" pour dire que le contenu du dossier est verrouillé ou pas ?
Dernière modification par anonyme (22-07-2017 13:39:14)
@enicar
merci pour l' explication
il faut retenir que le contenu de lock est nul , et que en cas d' absence il sera recréé ( la date de création aucune importance )
nota : il y a un espèce de drapeau sur le fichier "lock" pour dire que le contenu du dossier est verrouillé ou pas ?
En fait c'est le fichier lock qui est verrouillé, on peut aussi verrouiller un répertoire mais ce n'est pas
ce qu'ils font à mon avis. Le « drapeau », c'est le verrou qui sera relâché dès que le fichier lock sera
fermé. Il existe plusieurs sorte de verrous avec flock : partagé ou exclusif. Dans ce cas ils doivent utiliser
un verrou exclusif…
Avec l'appel de fcntl c'est plus fin, on peut poser des verrous en lecture, en écriture ou en lecture/écriture. ce verrou peut concerner une partie du fichier ou le fichier en entier… mais il n'y a pas la notion de partagé/exclusif.
Hors ligne
Dernière modification par enicar (22-07-2017 14:14:15)
Hors ligne
tu parle de plusieurs OS sur cette machine , pas de mélange ? , partitions commune ?
en simulation que donne
ah oui peut être une piste, j'avais lu sur un forum que sa posait des problémes de mélange de version de fichiers pour le home commun pour un même utilisateur sur different OS, ils donnaient quelques exemple d'ailleur
Par contre je ne saurais dire les symptomes
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
anonyme a écrit :tu parle de plusieurs OS sur cette machine , pas de mélange ? , partitions commune ?
en simulation que donne
ah oui peut être une piste, j'avais lu sur un forum que sa posait des problémes de mélange de version de fichiers pour le home commun pour un même utilisateur sur different OS, ils donnaient quelques exemple d'ailleur
Par contre je ne saurais dire les symptomes
À mon avis ça n'expliquerait pas le message au sujet du verrou. Le verrou, c'est une fonction interne du noyau
et n'existe que sur un fichier ouvert… autant dire que quand on éteint la machine le verrou n'existe plus.
Hors ligne
et mon idée d'enlever les utilitaires de mise a jour auto et aptitudes , bonne ou mauvaises idée ?
Pourquoi pas, on peut toujours essayer. De mon côté je me posais des questions au sujet de packagekit qui
lui aussi permet d'installer, de supprimer mettre à jour… et qui est utilisé par kde ou gnome par exemple.
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
Les utilitaires de mise a jour demande le mot de passe root donc pas activé tant que le passe est pas renseigné non?
Pas tous, unattended-upgrade ne demande rien vu que ça se fait à notre insu. Avec packagekit c'est possible
de faire des mises à jour sans le mot de passe root, il me semble ; c'est un service dbus…
Du coup, je serais pour supprimer packagekit et unattended-upgrade bien que ces paquets étaient
installés sur ma machine sans poser de problème particulier. De toute façon, on peut les réinstaller
si nécessaire.
Dernière modification par enicar (23-07-2017 10:33:48)
Hors ligne
Puis si ça renvoie un nombre, c'est le pid du processus qui l'utilise ; donc pour savoir qui :
Et il faut vraiment être root, sinon si le fichier tester avec fuser ne nous appartient pas
fuser ne répond rien et sans avertissement.
Dernière modification par enicar (23-07-2017 10:41:21)
Hors ligne
me renvoie 3 numéros de PID (2 apt.systemd.dai + 1 apt-get)
La commande
ne renvoie rien.
La commande
me renvoie
Et au sujet des différents OS, aucun partage de partition normalement (mais j'avais une distrib Ubuntu qui ne démarait plus suite à une MAJ, que j'ai peut-être écrasé mais pas sur) Y a-til une commande pour voir ça ?
Hors ligne
je suis donc passé par
avant de refaire:
Hors ligne
fonctionne, mais bloque à 0% sur la récupération n°15 de souvenirs...
Du coup, je suis obligé de fermé le terminal, et lorsque j'en ouvre un nouveau :
Le verouillage recommence, alors que faire ?
Hors ligne