J'ai un apt-get installprocessus qui semble être désespérément bloqué à l' processing triggers for python-supportétape.
Mon penchant est pour killcela, mais dans le passé, la simple réalisation d’ killun apt-get installprocessus m’avait causé beaucoup de chagrin. (Des fichiers de verrouillage assortis de l'IIRC sont laissés, etc.)
Existe-t-il un moyen plus sûr d’arrêter ce processus?
Réponses:
En règle générale, pour tuer un processus, il n'y a pas de moyen plus sûr de tuer un processus qu'avec un kill normal (SIGTERM). S'il s'agit d'un processus interactif, il vous permet généralement de l'arrêter encore plus sûrement en envoyant un signal SIGINT, généralement en appuyant sur Ctrl+ C. Ce signal est piégé par le processus lui - même, il peut l' écouter - et s'arrête normalement. ( merci Elia )
En ce qui concerne la gestion des paquets est une sorte de cas particulier. La base de données DPKG que les commandes APT utilisent sous l'eau peut toujours détecter si une opération n'est pas terminée. Chaque paquet a un état réel qui est marqué ainsi qu'un état actuel , par exemple, décompressé, configuré, etc. En tuant l'interface APT, la base de données sera dans un état cassé, mais dans un état connu . Les fichiers de verrouillage ne seront libérés que lorsque tout sera à nouveau en état de nettoyage: vous devriez le corriger jusqu'à ce qu'il permette de nouvelles opérations.
La solution consiste simplement à lancer un processus pour obtenir tous les packages dans l'état configuré. En pratique, si vous avez interrompu une apt-getopération, vous pouvez simplement la terminer plus tard en utilisant
sudo dpkg --configure -a
Il sait comment passer de l'état brisé à un état entièrement configuré et continuer en ce sens là où il avait été interrompu. Les fichiers de verrouillage sont conservés jusqu'à ce que vous ayez terminé, et cela pour une raison - d'empêcher de nouvelles opérations avec la base de données DPKG dans un état impur.
L'envoi d'un SIGKILL (représentation décimale 9) est très dangereux. Ce signal n'est pas capturé par le processus, mais le processus entier sera nettoyé par le système d'exploitation (noyau), que le processus le veuille ou non. L'état des fichiers sur le système de fichiers peut être corrompu. N'envoyez jamais ces signaux, sauf si vous n'écoutez plus d'autres signaux plus gracieux.
Quand je rencontre un échec avec apt-get, je fais ce qui suit (en tant que root, c'est-à-dire sudoavant toutes les commandes):
Tuez le processus nommé apt-get:
killall -9 apt-get
Reconfigurer dpkg:
dpkg --configure -a
Mettre à jour apt-get:
apt-get update
Packages de mise à jour, y compris ceux mal installés:
apt-get upgrade
J'ai appris cela quelque part, mais malheureusement, je ne me souviens pas exactement où.
Linux et d’autres systèmes de type Unix sont très puissants en ligne de commande, mais ils ne pardonnent pas une fois le processus démarré. L'envoi d'un processus par le signal kill va certainement tuer le processus en cours d'exécution, mais gardez à l'esprit que vous laissez une base de données dans un état instable. Le dernier enregistrement peut ne pas être fermé correctement et vous risquez de devoir réparer une base de données. Pas seulement avec apt mais avec n'importe quelle application.
Essayez toujours de terminer l'application de manière normale et ne supprimez que les processus exécutés par des applications.
Voici comment je le fais Ctrl+, Cmais notez bien que c'est sûr tant qu'apt-get est en phase de téléchargement ou qu'il met à jour le cache. Autre que cela, je ne peux pas penser à un moyen plus sûr. Laissez-le finir et annuler les modifications en désinstallant ou en rétrogradant. Les fichiers téléchargés peuvent être nettoyés avecsudo apt-get autoclean