1 votes

Ubuntu 14.04 se fige de manière aléatoire après de longues périodes et ne redémarre pas automatiquement (crontab)

Depuis un certain temps maintenant, j'ai des problèmes avec mon installation d'ubuntu 14.04 sur mon pc assemblé. Le composant principal est la carte mère, une ASRock Q1900M Pro3, 4gb ram, et deux contrôleurs pci sata.

J'utilise cet ordinateur comme serveur domestique, les fonctions principales sont le partage de fichiers (samba), serveur web local (LAMP), téléchargeur bittorrent (Tixati) et "station de muxing" (parce que j'en ai besoin, ne demandez pas). En plus de cela, je l'utilise pour naviguer sur le web lorsque je n'ai pas besoin d'allumer mon ordinateur principal, qui consomme 3 fois plus d'électricité lorsqu'il est inactif.

Je ne peux pas installer la version serveur d'ubuntu parce que Tixati ne fonctionnerait pas et que la navigation sur Internet et le muxing seraient une tâche difficile. De plus, un environnement de bureau en général est bien plus utilisable que la ligne de commande.

J'ai deux types de problèmes :

  • la machine s'arrête aléatoirement de fonctionner après un temps assez long assez long entre la mise sous tension et le fonctionnement (les problèmes surviennent après environ 24+ heures de fonctionnement, parfois plus tôt). heures de fonctionnement, parfois même plus tôt). Le gel se produit la plupart du temps la plupart du temps lorsque je n'utilise pas directement l'ordinateur, mais 2 ou 3 fois, il s'est figé pendant que j'étais en train de saisir des données. pendant que je donnais des informations. L'effet est que l'écran se fige à la l'écran se fige sur la dernière image traitée (je suppose) et TOUT type d'entrée est ignorée. J'ai également observé qu'il se déconnecte du réseau local. mais les LEDs Ethernet fonctionnent toujours, avec la LED verte de liaison toujours allumée toujours allumée et la LED orange d'activité clignotant un peu sans aucune fréquence spécifique (on peut dire aléatoirement). Depuis le routeur dd-wrt je peux voir que l'hôte est déconnecté et si j'essaie d'envoyer un ping au PC, j'obtiens 100% de perte de 100% de perte de paquets (en plus du fait que le partage samba est hors service). Le voyant d'activité du disque dur ne clignote pas du tout dans cet état. La seule façon La seule façon de redémarrer la machine est la méthode dure (en maintenant le bouton d'alimentation bouton d'alimentation enfoncé). Lorsque je vérifie le fichier journal dmesg, je ne trouve aucune entrée suspecte avant le gel. aucune entrée suspecte avant le gel, la dernière fois que cela s'est produit la dernière la dernière entrée était crontab exécutant un travail automatique, mais d'autres fois il quelque chose d'autre, comme le blocage de l'ufw. L'écran ne se L'écran ne se désactive jamais pour que je puisse voir la dernière chose avant qu'il ne se fige. Je n'ai jamais vu de messages d'erreur d'aucune sorte. c'est qu'une fois, l'écran était entièrement gris, et je ne l'ai pas laissé comme ça.
  • Pour résoudre ce problème, j'ai pensé que peut-être si je le faisais automatiquement automatiquement une fois par jour à l'aide de crontab résoudrait le problème, mais c'est que j'ai rencontré le deuxième problème dont je veux vous parler. Le deuxième problème est que la plupart du temps, la crontab redémarre le PC, il l'éteint avec succès, mais ne réussit pas à effectuer démarrage qui en découle, laissant le système suspendu dans les limbes entre la fin du Grub et le début du chargement du disque dur vers la mémoire vive. Il reste juste là avec un écran violet, n'affichant aucun message, même si j'utilise l'option "texte" (ou en supprimant le splash silencieux) dans le fichier Grub (oui, en faisant la mise à jour Grub après les modifications du fichier). La partie amusante partie amusante est qu'à partir de cet état, je dois arrêter le système de façon lorsque je le rallume, la séquence de démarrage fonctionne parfaitement, le Grub s'affiche, entre dans l'option sélectionnée après 10 secondes (démarrer ubuntu normalement) et le système démarre avec tous les messages du noyau s'affichant correctement et rapidement. J'ai essayé l'option repair boot tool automatic fix automatique, elle a fonctionné pendant 4-5 redémarrages automatiques mais pour une raison quelconque, elle ne mais pour une raison quelconque, cela ne fonctionne plus, même si je l'exécute à nouveau.

voici l'analyse initiale de la réparation du démarrage http://paste.ubuntu.com/12589606/

Voici le fichier journal dmesg http://paste.ubuntu.com/12632375/

  • ligne 1192 : system freeze forced reboot -> pas d'erreurs enregistrées
  • ligne 2399 : échec du redémarrage automatique, le système se bloque entre Grub et le le chargement des fichiers dans la mémoire vive -> aucune erreur n'est enregistrée
  • ligne 5423 : redémarrage manuel pour installer les mises à jour, le système se bloque entre Grub et le chargement des fichiers dans la ram -> aucune erreur enregistrée

galerie de mes paramètres bios : j'y travaille

vidéo du comportement du pc lorsqu'il est en état de gel : on y travaille

vidéo de l'échec du redémarrage automatique du pc : on y travaille

Faites-moi savoir si vous avez besoin d'informations supplémentaires. Merci pour votre aide.

0voto

waltinator Points 32821

Il ne s'agit pas d'une réponse complète. Puisque vous avez un système fait maison, j'ai lu l'article sur le système. dmesg avec la paranoïa réglée sur High et le filtre de confusion réglé sur Low (très paranoïaque, facilement confus dans le moi virtuel), et j'ai trouvé plusieurs éléments intéressants :

Ce site pourrait être problématique, vous devriez enquêter.

623 Sep 30 07:43:26 ubuntu-server kernel: [    0.907105] hpet: number irqs doesn't agree with number of timers

Envisagez d'installer thermald .

672 Sep 30 07:43:26 ubuntu-server kernel: [    0.998865] Consider also installing thermald for improved thermal control.

C'est celui que je soupçonne vraiment. Quels sont les processus que vous exécutez en "temps réel" ? Si un processus en temps réel perd la tête, il peut consommer TOUT le CPU, et ressembler au problème que vous avez signalé. (tout comme une panne soudaine du système d'exploitation). Pourriez-vous fonctionner pendant un certain temps sans rtkit ?

1086 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully called chroot.
1087 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully dropped privileges.
1088 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully limited resources.
1089 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Running.
1090 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Watchdog thread running.
1091 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Canary thread running.

1093 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2010 of process 2010 (n/a) owned by '1000' high priority at nice level -11.
1094 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Supervising 1 threads of 1 processes of 1 users.

1097 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2083 of process 2010 (n/a) owned by '1000' RT at priority 5.
1098 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Supervising 2 threads of 1 processes of 1 users.
1099 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2084 of process 2010 (n/a) owned by '1000' RT at priority 5.
1100 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Supervising 3 threads of 1 processes of 1 users.

Problème dans le système de journalisation ? Corrigez cela sur les principes généraux.

3293 Oct  1 08:02:11 ubuntu-server rsyslogd-2039: Could no open output pipe '/dev/xconsole': No such file or directory [try http://www.rsyslog.com/e/2039 ]

Et c'est un arrêt normal :

3935 Oct  1 08:10:42 ubuntu-server rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="967" x-info="http://www.rsyslog.com"] exiting on signal 15.

Pour se rapprocher de la dernière entrée du journal avant le crash, lancez ceci dans un Shell (afin qu'il ne redémarre PAS automatiquement) :

# set nap to sleep time (GNU sleep takes floating point values)
nap=2.5
# forever, or until the world ends
while [[ : ]] ; do
    dmesg -T >logfile
    sleep $nap
done

Après le crash, vérifiez la date de modification et le contenu de logfile . Augmenter la valeur de $nap pour diminuer la charge du système par ce biais, diminuez la valeur à stocker dmesg plus proche du moment du crash (au prix d'une charge plus importante). Mais il s'agit d'un débogage temporaire, donc vous ne vous souciez pas beaucoup de la charge. Faites en sorte qu'entre le dmesg -T >logfile et les données étant conservées sur le disque, il y a une surcharge, une mise en mémoire tampon, etc. Si le système se plante avant que les données n'atteignent le disque, elles seront perdues, mais il est difficile de déboguer le matériel et/ou le temps réel.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X