web-dev-qa-db-fra.com

Comment tuer un processus dont je sais qu'il gèle mon ubuntu?

J'ai un processus (TRAIN) qui tourne et j'ai également démarré kdevelop et essayé de construire une application. Ensuite, il a gelé. Tout est figé, pas de souris, pas de changement de bureau (Ctrl + Alt + flèche). J'ai également essayé Alt + F2 ou Ctrl + Alt + F1, mais rien ne se passe. J'ai également essayé les Alt + PrtScr et R + E + I + S + U + B, mais rien. J'ai un clavier français qui n'a pas de boutons SysRq et Fx disponibles lorsque l'on appuie sur Fn, c'est très étrange ... Y a-t-il autre chose que je peux essayer? Je ne veux pas perdre le processus TRAIN qui passe de 4 dais et qui forme un classificateur d'images; il est sur le point de terminer son travail (un jour de plus) ... Merci.

1
sop

Si le DE a gelé, passez à un autre niveau d'exécution en utilisant ctrl-alt-f3 et connectez-vous au terminal présenté. Vous pouvez tuer tous les processus incriminés en utilisant kill ou killall, si le DE est entré dans le blocage, il peut être utile de tuer xorg par Sudo killall Xorg pour redémarrer le DE (vous ramène généralement à DM pour vous connecter), revenez au niveau d'exécution graphique avec ctrl-alt-f7.

Si vous ne parvenez pas à arrêter le processus incriminé comme décrit, vous pouvez également essayer d'activer ctrl-alt-backspace pour tuer le xserver sans permuter les niveaux d'exécution, comme un dernier effort pour éviter un redémarrage sur un coup dur.

Comme d'autres l'ont dit, il peut être utile de retirer la dernière version du logiciel si les plantages sont prévisibles et réguliers - indiquant un bogue (s'il n'est pas disponible sur le repo, vérifiez les ppa ou apprenez à installer à partir de la source), cependant cela n'est pas toujours possible, il est donc utile de savoir comment récupérer un système sans réinitialisation matérielle.

Il existe des options disponibles pour restreindre la possibilité pour une application de planter le système, au plus simple, vous pouvez essayer d'exécuter le processus incriminé avec Nice pour réduire la priorité afin que les tentatives de verrouillage des ressources n'affectent pas d'autres processus. Selon la séquence exacte des appels menant au crash, il peut y avoir d'autres façons de mettre en sandbox l'application pour éviter ce blocage répété.

[~ # ~] modifier [~ # ~] : Personnellement, j'utilise LXC = pour les bacs à sable virtuels légers afin de maintenir les environnements de développement séparés du système de base, il peut être utile dans votre cas de faire de même, les applications graphiques utilisent leur propre instance de Xorg et ainsi les plantages n'abattront pas votre système hôte, l'accès aux graphiques la sortie est facilement réalisée avec xpra (et comme le sandbox fonctionne localement, vous n'avez aucun problème de latence avec le transfert de X sur ssh). Vous pouvez également voir les réponses à cette question pour d'autres options sur le sandboxing

PENSÉES SUPPLÉMENTAIRES : Si X a bloqué et ne répond pas à l'entrée du clavier (mais que le système d'exploitation lui-même n'a pas planté), vous pouvez également essayer de tuer le traiter à distance via sshou un autre système de console à distance.

2
crasic

Ouvrez un Moniteur système à partir de Dash -> Aller au 1er onglet Processus. Vous pouvez y tuer n'importe quel processus, juste clic droit sur le processus que vous voulez tuer et sélectionnez kill process.

0
Apurva

Si vous savez que ce processus/programme plante toujours votre ordinateur (TRAIN ou kdevelop ou autre), alors vous devriez vraiment arrêter de l'exécuter. Recherchez une version mise à jour qui pourrait ne pas tout planter, sinon la désinstaller/la supprimer serait une bonne idée.

Si vous devez absolument l'exécuter, je vous suggère d'exécuter Ubuntu dans un VM (machine virtuelle, comme VirtualBox) et d'exécuter le programme/processus instable à l'intérieur de celui-ci. Au moins alors quand il le plante devrait ne geler que le VM et laisser votre ordinateur continuer à fonctionner.

Et regardez dans votre clé SysRq, devrait être disponible en cas d'urgence la prochaine fois.

0
Xen2050