VS Code provoque 17.10, 18.04 gel complet et aléatoire
Veuillez lire: Voir le dernier bit. Je ne crois pas qu'il s'agisse d'un problème lié à Ubuntu, mais plutôt à VS Code.
Récemment, sous 17.10 et 18.04 (je viens de faire une mise à jour), Ubuntu va se figer de manière aléatoire et complète. Je ne peux pas déplacer le curseur ni utiliser le clavier. Naturellement, j'ai essayé de passer à une session TTY sans succès. A chaque fois, je dois avoir recours à SysRq + REISUB, ce qui n'est (évidemment) pas préféré.
J'ai essayé de changer de pilote graphique, en partant du principe que c'est peut-être le cas. J'utilisais à l'origine le pilote Open Source nVidia, et je suis passé en mode propriétaire en vain. J'utilise actuellement le pilote open source.
Tout ce que j’ai généralement ouvert est Firefox (pas une tonne d’onglets chargés ) et VS Code, avec au plus quelques fichiers et un terminal ouvert.
Des idées?
Mise à jour: les journaux système ne montrent aucune indication de quoi que ce soit , même si quelque chose ne va pas. Je ne sais pas si cela est lié, mais parfois (surtout après le démarrage), les programmes prennent beaucoup de temps (> 5 à 10 secondes), même les programmes en ligne de commande.
Encore une mise à jour! - Même avec toutes les extensions GNOME désactivées, il s'est toujours écrasé. J'ai essayé XFCE, qui s'est toujours écrasé.
Résumé: Ubuntu se fige complètement à des moments apparemment aléatoires, ne laissant aucune trace dans les journaux et n'est liée à aucun environnement de bureau spécifique ni aux extensions GNOME.
Mise à jour (probablement finale): Je suis convaincu qu'il s'agit d'un problème avec VS Code. Cela fait des jours que je fais tourner GNOME, avec d’autres applications Electron ouvertes (Slack, Pulse, etc.) et je n’ai pas eu un seul gel. J'ai DM's VS Code sur Twitter et vais probablement déposer un rapport de bogue car ils n'ont pas encore répondu.
Donc, il s'avère que cela n'est pas spécifique à Ubuntu, mais je posterai ceci ici de toute façon pour référence future.
Apparemment, même si j'ignore certains fichiers en utilisant le paramètre files.exclude (notamment le répertoire ./node_modules), VS Code reste surveille ces fichiers pour les modifications.
Pour résoudre ce problème, copiez simplement la liste de files.exclude dans files.watcherExclude. Ceci empêchera VS Code de rechercher parmi les milliers de fichiers contenus dans node_modules ou d’autres répertoires similaires. De cette façon, il laissera certains RAM pour que Chrome gobe.
Je viens de courir dans cela. Lors du lancement, dans un grand projet, mon système se figeait au bout de 20 secondes environ et ne répondait plus (Ubuntu 18.04). Exécuter htop lors du lancement de VSCode a montré que tous les cœurs étaient portés à 100% (i7-8700K), consommaient toute la mémoire (16 Go), puis l’échange. Le gel est arrivé quelques instants plus tard. Cela se passait à cause d'une mauvaise extension, dans mon cas c'était CSS Peek.
Essayez donc de lancer vscode avec les extensions désactivées (code --disable-extensions) et voyez si cela se produit toujours. S'il ne détecte pas l'extension défectueuse et l'envoie en enfer.
J'ai eu des gels complets au hasard et j'ai passé plusieurs heures à essayer de comprendre pourquoi. Au redémarrage, les journaux n'étaient vraiment pas utiles. Au départ, je pensais que c’était le pilote nvidia, mais non, juste une extension VSCode.
J'ai eu le même problème. Finalement, j'ai réalisé que dans mon cas, le problème venait à manquer de mémoire (j'ai 8 Go de RAM et seulement 1 Go de partition swap sur le disque). J'ai résolu ce problème en allouant de l'espace de swap supplémentaire à l'aide du fichier de mon répertoire racine:
Sudo fallocate -l 1G /swapfile
Sudo chmod 600 /swapfile
Sudo mkswap /swapfile
Sudo swapon /swapfile
cela permettra temporairement d'activer 8 Go supplémentaires de swap pour votre système. Si cela peut vous aider, ici vous pouvez lire en permanence des instructions supplémentaires permettant d'activer le nouvel échange.
Vous pouvez également ajouter physiquement RAM ou ajouter/agrandir une partition de swap.
J'ai utilisé un nouveau fichier d'échange en tant que fichier car mon système était chiffré par luks + lvm et le redimensionnement d'une partition d'échange existante est trop compliqué et risqué dans mon cas.
P.S. J'ai eu Ubuntu 18.04
J'ai également souffert de pannes système aléatoires lors de l'exécution de VSC. Même essayé de commencer sans extensions, ce qui ne m'a pas aidé du tout. Quelques fois, mon système a gelé juste au démarrage de VSC.
Cependant, j’ai vérifié les journaux et découvert que ces blocages pouvaient être corrélés au pilote graphique (NVidia GTX 660).
Solution dans mon cas: Passage du pilote Nouveau au pilote propriétaire (j'ai choisi le métapaquet)
Btw: Utiliser Ubuntu 18.04