Durée maximale pendant laquelle un PC Linux peut être UP? [fermé]


12

En fait, j'avais un système Linux (exécutant Ubuntu 12.04.3) pendant des jours sans redémarrage. J'ai rencontré des erreurs telles que le sommeil se bloquait et certains systèmes de fichiers montés sur le réseau ne recevaient même pas le montage (vérifié via un autre PC, le montage réseau fonctionnait bien).

Je voulais vérifier si Linux nécessite également de redémarrer la machine après un certain laps de temps pour éviter ces types d'erreurs qui ne sont pas répétables.

Quelle est la durée maximale pendant laquelle nous pouvons maintenir le PC en marche? Y a-t-il d'autres problèmes qui pourraient survenir si nous avons un système en place pendant un an ou plus sans redémarrage?


2
Je ne pense pas qu'il y ait une limite statique, car les ordinateurs ne sont tout simplement pas destinés à être éveillés et à fonctionner pendant si longtemps. Il n'y a pas de limite nominale; c'est juste combien de temps votre ordinateur peut rester allumé. Pourquoi ne voudriez-vous pas redémarrer de temps en temps.
TheWanderer

7
@ Zacharee1 umm, pourquoi voudriez-vous redémarrer? À moins que ce soit la consommation d'énergie, il n'y a vraiment pas beaucoup de raison. En fait, c'est mieux si vous ne le faites pas. Le matériel durera généralement, X ans par pièce. Supposons pour simplifier que X est universellement 10 (ce ne sera pas loin non plus) - c'est généralement 10 années d'utilisation continue qu'il peut durer. C'est une utilisation normale. Si vous redémarrez, ce n'est pas une utilisation continue, mais vous frappez également le gros matériel la prochaine fois que la machine démarre. Si vous vous contentez de le laisser - la plupart des composants ralentissent, réduisent la consommation et l'usure de toute façon.
VLAZ

1
Il est évident que les pièces subissent plus d'usure lors de leur utilisation. Cependant, le redémarrage (par opposition à l'arrêt du système) ne diminue pas l'usure des composants, il l'augmente. En outre, vous comprenez fondamentalement le fonctionnement des caches si vous pensez que les données mises en cache dans la RAM ralentissent votre ordinateur.
user6053

1
Si vous utilisez un serveur Web sous Linux (par exemple LAMP), vous voulez éviter autant que possible les redémarrages, car cela entraînerait une baisse de vos sites Web pendant le temps nécessaire au système pour revenir. Je ne pense pas avoir jamais passé un an mais certainement plusieurs mois sans redémarrer.
tcrosley

2
@ Zacharee1 à peu près n'importe quoi dans la RAM ne ralentirait pas votre ordinateur. S'il y a une fuite de mémoire dans une application, cela pourrait prendre, disons, 60% de la RAM et le système commencerait bientôt à échanger ce qui est lent, cependant, la solution est de redémarrer l'application, pas le système d'exploitation. L'arrêt de la machine arrête l'usure des composants, mais vous les remplaceriez plus tôt qu'ils ne le font généralement dans la plupart des cas. Et de plus, comme je l'ai souligné, les composants matériels diminuent déjà l'usure par eux-mêmes. Simplement en laissant le système inactif.
VLAZ

Réponses:


36

En tant qu'administrateur système, je vois des serveurs Linux fonctionner pendant plus de 700 à 800 jours sans redémarrage, il n'y a donc aucune limitation de disponibilité; les erreurs que vous avez obtenues ne sont pas liées à Linux (le noyau) lui-même.

De nombreux services peuvent être redémarrés et la plupart des erreurs peuvent être résolues sur les systèmes de production.


7
Je peux le confirmer. Disponibilité actuelle sur l'un de mes serveurs: ~ disponibilité $ 00:13:15 jusqu'à 883 jours, 9h00, 1 utilisateur, charge moyenne: 0,00, 0,01, 0,05 Ubuntu 12.04.4 LTS. Pas besoin de mettre à jour quoi que ce soit car il n'exécute rien d'important.
Minthos

5
J'ai réussi à maintenir une instance Linux embarquée pendant plus de 3 ans.
Rafał Cieślak

16

Il n'y a aucun besoin technique de redémarrer votre ordinateur après une certaine période de temps. J'ai eu le mien en cours d'exécution pendant des mois (y compris les mises à jour du module du noyau) avec quelques suspensions (vers la RAM et le disque) entre les deux.

Il y a des occasions où

  • il est absolument nécessaire de redémarrer, comme les mises à jour du noyau (mais celles-ci ne sont pas urgentes dans de nombreuses situations, et dans certains cas, vous pouvez remplacer un noyau en cours d'exécution par un nouveau sur un système vivant. Voir kexec et Ksplice )
  • il peut être plus facile de redémarrer l'ensemble du système au lieu d'un seul (ensemble de) sous-système (s).

Il peut y avoir des problèmes qui «s'aggravent» avec le temps (par exemple, des problèmes de pilote matériel, des processus qui fuient), mais ceux-ci sont considérés comme des bogues et peuvent souvent être corrigés avec une mise à niveau logicielle ou contournés par un rechargement / redémarrage de ce sous-système particulier (également voir au dessus).


6
À la volée, les correctifs du noyau obtiennent plus de battage publicitaire qu'il ne le mérite. C'est génial si vous avez le temps de vérifier qu'une mise à jour fonctionnera de cette façon, mais tout changement de code qui rend les structures de données en mémoire différentes ne peut pas simplement être corrigé en direct. Cela ne va pas permettre la mise à niveau sans redémarrage vers de nouveaux noyaux en général. Il permettra des correctifs sans redémarrage pour des choses comme les bogues de vérification des autorisations. C'est génial et génial de ne pas avoir à redémarrer un serveur, mais ne vous attendez pas à ce que cela vous donne des mises à niveau sans redémarrage vers de nouvelles versions.
Peter Cordes

1
Je suis d'accord avec Peter. C'est pourquoi je n'ai pas mentionné le patching en direct dans ce contexte pour ne pas compliquer les choses; hélas, quelqu'un a modifié ma réponse.
David Foerster

7

Bien que je sois certain qu'il existe des serveurs avec une disponibilité plus élevée, je présente ce qui suit de l'un des miens comme exemple de ce qui est possible:

# uptime
04:58:44 up 2186 days, 23:15,  1 user,  load average: 0.02, 0.02, 0.00

Ce serveur a été installé peu de temps après la mise en service du contrôleur de domaine et n'a pas été éteint depuis. Jusqu'à présent, il a continué à faire ce pour quoi il était initialement prévu et lorsque cet objectif sera déplacé sur un autre serveur, je mettrai quelque chose là-bas juste pour surveiller la disponibilité et il restera probablement jusqu'à ce que je ne puisse pas justifier de le maintenir en vie plus longtemps.

Ainsi, je pense que "il n'y a pas de maximum" est certainement la bonne réponse.


7

Je ne sais pas si cela a un impact sur la stabilité du système, mais le temps de disponibilité maximal affiché dans Ubuntu avec le noyau 3.19-xx est de plusieurs 68,0962597349822années sur une machine 32 bits et de plusieurs 292471208677,8627années sur une machine 64 bits.

C'est parce que la disponibilité actuelle du système, qui est renvoyée par l' sysinfo()appel système, est renvoyée comme un __kernel_long_ttype , qui est déclaré comme un longdans un noyau 32 bits et comme un long longdans un noyau 64 bits ;

A longsur une machine 32 bits a une valeur maximale de2147483647 ;

A long longsur une machine 64 bits a une valeur maximale de 9223372036854775807;

Faire le calcul, 2147483647s= 68,0962597349822années et 9223372036854775807s=292471208677,8627 années.

Une fois que cette valeur augmente dépassant la capacité de son type, un débordement arithmétique a lieu et il est défini sur la plus petite valeur autorisée par son type (dans les deux cas, un nombre négatif): cela pourrait être un problème pour les programmes qui en dépendent.


3
L'OP ne demande pas le temps de fonctionnement maximum que le système peut enregistrer avec précision, il demande s'il devra redémarrer son système régulièrement en raison d'une certaine stabilité / etc. limitation.
Boluc Papuccuoglu

@BolucPapuccuoglu Voyez si, à votre avis, il s'intègre mieux dans ce format, en particulier la dernière partie. J'ai indiqué explicitement quel pourrait être le problème. Si vous pensez toujours que non, je supprimerai ma réponse.
kos

6

J'étais dans une classe une fois avec un administrateur système qui a affirmé qu'il avait un serveur Linux qui fonctionnait sans redémarrage depuis plus d'une décennie. Il n'y a aucune raison inhérente au redémarrage régulier d'un système. Il n'est requis que dans des cas limités tels que les mises à jour du noyau.

FWIW, je laisse généralement mon ordinateur personnel Windows en marche. Il fonctionnera généralement très bien pendant des semaines sans redémarrer.


Si votre ordinateur Windows passe des semaines sans redémarrer, vous n'avez évidemment pas activé les mises à jour automatiques. Ils sont généralement téléchargés chaque semaine et entraînent presque toujours un redémarrage.
tcrosley

@tcrosley Qui a quand même besoin de mises à jour automatiques? C'est l'une des premières choses que j'éteins sur ces machines. Je vais décider comment utiliser mon ordinateur, pas un service automatique.
mât

@tcrosley Êtes-vous sûr que les mises à jour de sécurité Windows sont généralement téléchargées chaque semaine? D'après ce que je comprends, à la fois des politiques de mise à jour de Microsoft et de mon expérience personnelle avec Windows, les mises à jour sont généralement publiées environ une fois par mois. Mast: Bien que vous soyez certainement libre de désactiver les mises à jour automatiques, je ne sais pas pourquoi cela entraînerait des temps de disponibilité plus longs. Vraisemblablement - j'espère! - vous mettez à jour manuellement, au moins pour les correctifs de sécurité. D'autre part, la désactivation automatique des mises à jour peut rendre plus facile à contrôler lorsque les temps d' arrêt se produit.
Eliah Kagan du

@EliahKagan J'ai la configuration de ma machine pour télécharger non seulement des correctifs de sécurité, mais aussi des mises à jour d'applications, de pilotes, etc. Je me trompe peut-être une fois par semaine, mais c'est certainement plus souvent qu'une fois par mois. Il vérifie les mises à jour tous les matins à 3h00. Je viendrai dans la matinée et constaterai que mon système a redémarré et après la connexion, il y a un message "Votre système a été redémarré pour installer les mises à jour".
tcrosley

4

Linux (le noyau) est très bon pour libérer des ressources lorsque les programmes se terminent. GNU / Linux, l'ensemble du système d'exploitation, peut généralement fonctionner indéfiniment. Le redémarrage des programmes de l'espace utilisateur après leur mise à jour est généralement une bonne idée, et souvent le moyen le plus simple de tout obtenir à l'aide d'une mise à jourglibc à est de redémarrer le système.

Sur les systèmes avec des bogues de pilote (généralement des bogues de pilote graphique, tout le reste est généralement solide), vous obtenez parfois un comportement étrange qui devient plus étrange si vous ne redémarrez pas rapidement. Si vous voyez un OOPS du noyau dans votre dmesgsortie, vous devez redémarrer dès que cela est pratique et le signaler (ou google autour pour d'autres personnes ayant des problèmes similaires sur du matériel similaire, au cas où ce serait un problème connu). Les discothèques ne livrent pas les toutes dernières versions de développement de la pile graphique, donc parfois le bogue est déjà corrigé en amont, et votre carte graphique est tout simplement trop nouvelle pour que les pilotes de la version de distribution que vous utilisez soient stables. Dans ce cas, recherchez un PPA avec des versions mises à jour de mesa / drm / xorg. (Je ne sais pas quel est le meilleur choix pour exécuter Ubuntu avec une pile graphique à la pointe de la technologie est ATM).

Quoi qu'il en soit, sauf pilote ou autres bogues du noyau, Linux peut fonctionner indéfiniment sans avoir besoin d'un redémarrage pour effacer la fragmentation de la mémoire ou quelque chose comme ça.

J'ai un routeur / pare-feu / serveur de messagerie / boîtier Linux (P3 450 MHz, OCed à 500 MHz) qui voit régulièrement des temps de disponibilité de centaines de jours. Je redémarre uniquement pour réorganiser les cordons d'alimentation ou pour remplacer une alimentation défectueuse. Cela se passe régulièrement avec les mêmes CPU / RAM / disques durs depuis probablement 15 ans. Je n'ai jamais eu à redémarrer "car ça devenait instable". C'était toujours pour une raison spécifique, comme une panne d'alimentation, une mise à niveau du noyau ou une panne de courant et la batterie de mon onduleur était presque épuisée (déclenchant l'arrêt automatique avec apcupsd).

Si votre système agit bizarrement, dmesgrecherchez les problèmes. Si c'est juste votre bureau, alors si vous venez d'installer des mises à jour de paquets non-noyau, déconnectez-vous / connectez-vous (ou redémarrez, mais vous n'êtes pas obligé de le faire). J'ai trouvé que Kubuntu 15.04 rencontrait facilement des problèmes après les mises à jour du paquet, je pense qu'en raison d'une incompatibilité binaire entre les versions mises à niveau / non mises à niveau de la même bibliothèque fonctionnant dans le même binaire. (Voir la discussion sur ce bug ).

Mon go-to pour vérifier les problèmes matériels est de démarrer memtest86 +. ( aptitude install memtest86+) Laisser cela exécuter un passage complet, ou courir pendant la nuit. Cela ne garantit pas un système stable, car la tension d'alimentation baisse sur les charges de pointe peut se produire avec les CPU ces jours-ci, et memtest ne l'exclut pas. Il ne chauffera pas non plus votre processeur, comme Prime95.


3

Ma machine n'a redémarré aujourd'hui que pour le 15.04 après avoir fonctionné pendant 11 jours sans erreurs étranges dont je me souvienne. Si vous effectuez un travail et un développement lourds sur un système, il peut parfois être la seule option à redémarrer, mais ce n'est que sur la base des besoins.


Exactement, vous avez raison! Je développe le 16.04 depuis quelques mois. En raison du gel, je redémarre généralement mon ordinateur tous les jours. Mais je suis sûr que la raison est ce que j'ai installé et que j'utilise sur et les pilotes, etc.
efkan

1

Techniquement, il n'y a pas de limites. il vous suffit de le mettre en veille ou de ne pas l'éteindre.


3
Pourriez-vous clarifier et élaborer davantage votre réponse? Surtout cette ligne you just have to set it to not sleep or shut down.
heemayl

«Techniquement, il n'y a pas de limites» aurait suffi comme réponse courte, concise et correcte.
Léo Lam

0

Personnellement, je ne voudrais pas faire fonctionner mon ordinateur portable ou mon PC pendant des jours sans redémarrer ou arrêter.

Tout simplement à cause des principaux composants qui génèrent de la chaleur peuvent accélérer l'usure du MB.

(C'est si vous n'avez pas le bon refroidissement et la bonne ventilation)


4
S'il s'agit d'ordures de consommation comme Acer ou HP, mais les Thinkpads de qualité professionnelle ou les ordinateurs portables Dell Latitude sont généralement mieux fabriqués; Personnellement, j'ai un Latitude fonctionnant 24h / 24 et 7j / 7 depuis plus d'un an maintenant, il est juste à côté de moi et fonctionne toujours parfaitement.

@kingtoor Pourquoi serait-il préférable d'exécuter une machine 24x7 insuffisamment refroidie avec des redémarrages occasionnels que de l'exécuter 24/7 sans redémarrages? (Ou n'est-ce pas ce que vous voulez dire?)
Eliah Kagan

1
Éteindre / dormir lorsqu'il n'est pas utilisé sur un ordinateur portable qui devient chaud lorsqu'il est exécuté 24h / 24 et 7j / 7, bien sûr. Cela n'a rien à voir avec le redémarrage (sans temps libre) par rapport à la disponibilité continue.
Peter Cordes

Ma réponse est dans mon commentaire.
Kingtoor

De plus, je ne vois pas vraiment de raison pour un utilisateur moyen de faire fonctionner son PC 24h / 24 et 7j / 7, sauf s'il a un serveur. C'est mon opinion.
Kingtoor

0

Pas spécifique à Ubuntu, mais j'ai un ordinateur portable vintage 1997 (300 MHz, 288 Mo de RAM) exécutant une distribution basée sur Debian qui a eu un temps de disponibilité supérieur à 60 jours, tout en exécutant un seul programme (plus des trucs système et conky) et ne pas démarrer et arrêter d'autres logiciels, sauf un terminal pour charger les mises à jour chaque semaine. Finalement, il s'est écrasé lors du chargement des mises à jour, à environ 63 jours. En revanche, mon système de bureau Kubuntu 14.04 se bloquera dans le verrouillage de l'écran après environ deux semaines. Je suis d'accord avec d'autres réponses; il s'agit davantage du logiciel que vous exécutez et de la fréquence à laquelle vous démarrez et arrêtez d'autres programmes que de Linux en tant que tel.


S'il s'est écrasé (je veux dire un crash ou un gel dur, pas seulement un crash X qui peut être réparé sans redémarrage), cela signifie probablement qu'il y a un problème matériel (surchauffe, mauvaise RAM, etc.). En tant qu'administrateur système, je fais parfois fonctionner mes serveurs pendant des mois sans redémarrer, bien que je préfère l'éviter car vous devez redémarrer pour appliquer les mises à jour du noyau.

Lorsque le verrouillage de l'écran est devenu noir, il n'y a aucun moyen efficace de savoir s'il s'agit d'un verrouillage système dur ou d'une défaillance du serveur X - et aucun moyen d'accéder à la ligne de commande (sans possibilité de saisir le mot de passe) pour redémarrer X ou quoi que ce soit d'autre Ça pourrait être. J'ai tendance à penser que si cela prend deux semaines, ce n'est pas une surchauffe ou une mauvaise RAM.
Zeiss Ikon

Ctrl + Alt + F1 ne fonctionne pas? Et un mauvais pilote graphique peut être le coupable - ils n'ont peut-être pas été testés avec un temps de fonctionnement élevé à l'esprit, mais Linux est certainement capable de fonctionner pendant des années sans problèmes.

Je vais devoir essayer CTL-ALT-F1, si je me souviens bien la prochaine fois que j'obtiens un blocage du verrouillage d'écran (j'ai utilisé la réinitialisation matérielle). Je suppose que je l'utiliserais ensuite startxpour redémarrer le serveur X? Ou dois-je utiliser une commande spéciale pour redémarrer le service? Je connais bien le vieil adage de Linux selon lequel "les redémarrages sont destinés aux mises à niveau du noyau et à l'installation matérielle".
Zeiss Ikon

Connectez-vous en tant qu'utilisateur root ou en tant qu'utilisateur normal et utilisez sudo, et suivez ces instructions
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.