Si on parle bien du load average tel qu'indiqué dans /proc/loadavg ou uptime(1), la mesure n'est pas en pourcents et un load de "3" peut très bien indiquer un système très largement sous utilisé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Donc pas de surcharge cpu, pas de io wait et utilisation du disque et du réseau faible.
Si le « load average » tel qu'affiché par uptime(1) est élevé, ça veut dire qu'il y a des processes en état R ou D. Ça veut dire qu'il y a soit du CPU qui est bouffé soit des I/O waits ou équivalents.
$ ps -eLo pid,user,stat,cmd | awk '$3~/[DR]/'
Si tu vois plein de trucs en état D, tu peux voir ce qu'ils fabriquent avec sysrq-t. Si c'est plutôt du R, sysrq-w.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Donc le truc c'est que si tu veux avoir accès au support ou à RHN pour un de tes systèmes RHEL, il te faut un contrat pour tous tes systèmes RHEL. Si tu as 42 RHEL avec seulement 2 enregistrées sur RHN, tu dois quand même payer pour les 42 sinon le contrat est rompu.
Les mises à jour sont gratuites.
Certains packages sont dans des canaux à part qui nécessitent de payer en plus.
Certains services qui sortent du cadre du support nécessitent de payer en plus pour obtenir de l'assistance de la part d'un consultant.
Les autres distributions ne sont pas concernées par l'EULA Red Hat, même si elles sont dérivées des mêmes src.rpm (CentOS, OEL,...).
En tout cas c'est comme ça que j'ai compris le fonctionnement quand je travaillais au support technique Red Hat mais je ne suis pas juriste. Si tu veux être sûr, parles à ton avocat et au service commercial/client de Red Hat.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Est-ce que tu peux reproduire le problème en redémarrant uniquement gdm (pas toute la machine) ? Si oui, tu peux stracer le démarrage de gdm et ça devrait te dire assez précisement ce qui prend du temps. Regarde les options -f -T et -tt de strace. Si tu comprends pas comment interpréter les résultats, essaie de trouver les plus grandes valeurs pour le dernier champs ("<12.345>", c'est le temps qu'a pris l'appel système avant de retourner).
Si le problème se produit uniquement au démarrage, il est probable qu'il s'agisse d'un service qui n'a rien a voir qui bloque le démarrage de gdm. Il devrait y avoir moyen de désactiver le splash screen et de faire en sorte que le démarrage de chaque service soit affiché en mode texte (c'est surement décrit qq part dans la doc de ta distro). Il reste alors à voir ce qui prend du temps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'ai pas lu la moitié de ton journal et aucun des commentaires mais ctrl-f me dit que personne n'a cité snowdrop (made in lcamtuf): http://lcamtuf.coredump.cx/soft/snowdrop.tgz
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je connais pas trop mdadm mais je suspecte que le problème est que tu utilises les devices sd comme devices sous-jacents à un md. Comme tu l'as remarqué, l'ordre de détection des devices peut changer et ce à quoi correspond chaque sd n'est donc pas constant. La solution est peut-être d'utiliser des noms persitants comme /dev/disk/by-uuid/ au lieu de /dev/sd*.
Je trouve intolérable que sur linuxfr on en vienne à mettre en première page des dépêches à peines traduites. Messieurs les modérateurs, merci de faire votre travail un peu plus correctement.
Mais du coup là je vais être moinssé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Bon sinon j'ai toujours pas compris comment faire des retours à la ligne avec ce nouveau site kikoolol. Vivement qu'on revienne à la version qui marchait.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
un qui contribue (red hat) et l'autre (oracle) non
Oracle contribue peut-être moins au développement du noyau mais ils contribuent quand même pas mal (272 patches dans le 2.6.37 contre 1265 pour Red Hat ou 128 pour Google par exemple) : http://lwn.net/Articles/420658/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
strace et gdb vont sans doute pas t'en apprendre plus que « ça bloque dans l'appel système stat() » (ou peut-être un autre mais je mise une cacahouéte sur stat()). Par contre, un sysrq-t va te permettre de voir dans quoi ça coince au niveau noyau. Donc "echo t > /proc/sysrq-trigger" et tu nous dit ce que tu vois dans les logs noyau concernant ce ps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si c'est pour compiler la version finale qui sera distribuée aux clients, oui. Si c'est pour faire un test de deux minutes d'un truc que t'es en train de développer dans ton coin, non.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Developers also usually have two or three test systems (sometimes more). We also have access to large test labs.
Donc, en principe ça n'empèche pas les tests fréquents sur des systèmes plus petits. Et personnellement, je trouve aussi qu'avoir une grosse bécane pour développer a plus de sens.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je ne suggérais pas d'attaquer qui que ce soit en justice. Je faisais juste remarquer que Red Hat paie pas mal d'avocats spécialisés pour penser à ce genre de trucs et que je doute qu'ils aient fait une erreur aussi simple. N'étant pas avocat ou juriste moi même je ne vais pas essayer de détailler ton erreur mais le bon sens me dit que légalement, Red Hat est en conformité avec les licences des logiciels qu'ils redistribuent.
Et légalement ni ce message ni ce thread ne vaut rien évidemment.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
comment un bug dans un driver peut-il amener un noyau linux sur un pc moderne à des pauses illimitées
Il y a plein de façons possibles et ça arrive tout le temps.
Même si le vrai problème provient d'un périphèrique ou firmware/BIOS défectueux, le driver correspondant peut sans doute être modifié pour ne pas causer un gel du système lorsque le matériel se comporte mal (évidemment ça dépend de ce qui se passe exactement).
NB : le bug n'était de toute façon pas vraiment lié à débian puisque se
produisant avec toutes les distributions que j'ai pu essayer de DSL
à fedora.
Va falloir apprendre à écrire des descriptions de bugs moins tordues alors.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: En gros
Posté par Krunch (site web personnel) . En réponse au message lecture du load average ? surtout niveau d'alarme ?. Évalué à 2.
Si on parle bien du load average tel qu'indiqué dans /proc/loadavg ou uptime(1), la mesure n'est pas en pourcents et un load de "3" peut très bien indiquer un système très largement sous utilisé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# load avg
Posté par Krunch (site web personnel) . En réponse au message High load. Évalué à 2.
Si le « load average » tel qu'affiché par uptime(1) est élevé, ça veut dire qu'il y a des processes en état R ou D. Ça veut dire qu'il y a soit du CPU qui est bouffé soit des I/O waits ou équivalents.
Si tu vois plein de trucs en état D, tu peux voir ce qu'ils fabriquent avec sysrq-t. Si c'est plutôt du R, sysrq-w.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Bonjour
Posté par Krunch (site web personnel) . En réponse au message Compréhension license RedHat. Évalué à 4.
Donc le truc c'est que si tu veux avoir accès au support ou à RHN pour un de tes systèmes RHEL, il te faut un contrat pour tous tes systèmes RHEL. Si tu as 42 RHEL avec seulement 2 enregistrées sur RHN, tu dois quand même payer pour les 42 sinon le contrat est rompu.
Les mises à jour sont gratuites.
Certains packages sont dans des canaux à part qui nécessitent de payer en plus.
Certains services qui sortent du cadre du support nécessitent de payer en plus pour obtenir de l'assistance de la part d'un consultant.
Les autres distributions ne sont pas concernées par l'EULA Red Hat, même si elles sont dérivées des mêmes src.rpm (CentOS, OEL,...).
En tout cas c'est comme ça que j'ai compris le fonctionnement quand je travaillais au support technique Red Hat mais je ne suis pas juriste. Si tu veux être sûr, parles à ton avocat et au service commercial/client de Red Hat.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# db.de > *
Posté par Krunch (site web personnel) . En réponse au journal Un concurrent pour Voyages-SNCF. Évalué à 5.
Login obligatoire, je vais même pas essayer. Je ne vois donc toujours pas de raison d'utiliser autre chose que db.de.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: HTTP PKI décentralisée
Posté par Krunch (site web personnel) . En réponse au journal SSL .... Évalué à 2.
Et puis il y a les gens qui veulent intégrer la crypto au niveau transport en remplaçant TCP :
http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.html http://mirror.fem-net.de/CCC/27C3/ogg-audio-only/27c3-4295-en-high_speed_high_security_cryptography.ogg
Rien à voir mais je comprend toujours pas comment faire un retour à la ligne. Et les erreurs 500 c'est pénible.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# strace
Posté par Krunch (site web personnel) . En réponse au message démarrage gdm anormalement lent. Évalué à 2.
Est-ce que tu peux reproduire le problème en redémarrant uniquement gdm (pas toute la machine) ? Si oui, tu peux stracer le démarrage de gdm et ça devrait te dire assez précisement ce qui prend du temps. Regarde les options -f -T et -tt de strace. Si tu comprends pas comment interpréter les résultats, essaie de trouver les plus grandes valeurs pour le dernier champs ("<12.345>", c'est le temps qu'a pris l'appel système avant de retourner).
Si le problème se produit uniquement au démarrage, il est probable qu'il s'agisse d'un service qui n'a rien a voir qui bloque le démarrage de gdm. Il devrait y avoir moyen de désactiver le splash screen et de faire en sorte que le démarrage de chaque service soit affiché en mode texte (c'est surement décrit qq part dans la doc de ta distro). Il reste alors à voir ce qui prend du temps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# j'ai rien lu mais
Posté par Krunch (site web personnel) . En réponse au message Tatouage de code source. Évalué à 6.
J'ai pas lu la moitié de ton journal et aucun des commentaires mais ctrl-f me dit que personne n'a cité snowdrop (made in lcamtuf): http://lcamtuf.coredump.cx/soft/snowdrop.tgz
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# nommage persistant des disques
Posté par Krunch (site web personnel) . En réponse au message disques mélangés au boot sur un Raid logiciel. Évalué à 2.
Je connais pas trop mdadm mais je suspecte que le problème est que tu utilises les devices sd comme devices sous-jacents à un md. Comme tu l'as remarqué, l'ordre de détection des devices peut changer et ce à quoi correspond chaque sd n'est donc pas constant. La solution est peut-être d'utiliser des noms persitants comme /dev/disk/by-uuid/ au lieu de /dev/sd*.
Il y a ça qui peut aider à comprendre un peu l'affaire :
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pourquoi vous abandonnez le projet ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Project-Builder.org 0.11.1 est maintenant disponible. Évalué à 3.
On peut la refaire au premier degré si tu veux.
Je trouve intolérable que sur linuxfr on en vienne à mettre en première page des dépêches à peines traduites. Messieurs les modérateurs, merci de faire votre travail un peu plus correctement.
Mais du coup là je vais être moinssé.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pourquoi vous abandonnez le projet ?
Posté par Krunch (site web personnel) . En réponse à la dépêche Project-Builder.org 0.11.1 est maintenant disponible. Évalué à 6.
Il y a une raison particulière pour laquelle vous abandonnez le projet ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Perdu
Posté par Krunch (site web personnel) . En réponse au journal Changeons de sujet. Évalué à 3.
Et que dire du robinet que tout le monde touche ?
http://www.smbc-comics.com/index.php?db=comics&id=1987#comic
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La journée de meuf !
Posté par Krunch (site web personnel) . En réponse au journal Changeons de sujet. Évalué à 9.
Chacun son truc hein.
http://bonjourapril.fr/ http://www.bonjourponey.fr/ http://www.bonjourlesenfants.fr/ http://www.bonjourtous.fr/
Bon sinon j'ai toujours pas compris comment faire des retours à la ligne avec ce nouveau site kikoolol. Vivement qu'on revienne à la version qui marchait.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: HS : A propos de RedHat…
Posté par Krunch (site web personnel) . En réponse à la dépêche Petites brèves : RHEL 4.9, Scientific Linux 6.0 et CentOS 4.9. Évalué à 4.
Les deux autres journals sur le sujet sont :
https://linuxfr.org/users/darkhad/journaux/lengagement-de-red-hat-envers-lopen-source
https://linuxfr.org/users/gbetous/journaux/esprit-du-libre-capitalisme
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: RE L'engagement de Red Hat envers l'Opensource
Posté par Krunch (site web personnel) . En réponse au journal L'engagement de Red Hat envers l'open source. Évalué à 3.
C'est peut-être pas super évident dans l'annonce mais c'est pas une première étape. Quelques mois plus tôt (juin 2010), la base de connaissance Red Hat est devenue accessible uniquement aux clients payants. Ce qui est assez amusant dans le sens où elle était devenue accessible à tous en mars 2006.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Position de combats
Posté par Krunch (site web personnel) . En réponse au journal L'engagement de Red Hat envers l'open source. Évalué à 6.
Oracle contribue peut-être moins au développement du noyau mais ils contribuent quand même pas mal (272 patches dans le 2.6.37 contre 1265 pour Red Hat ou 128 pour Google par exemple) : http://lwn.net/Articles/420658/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Open Source != Logiciel Libre
Posté par Krunch (site web personnel) . En réponse au journal Esprit du libre = Capitalisme. Évalué à 2.
Donc en fait tu découvres l'Open Source et pourquoi le mouvement a été crée suite au Logiciel Libre.
http://fr.wikipedia.org/wiki/Logiciel_Libre#.C2.AB_Logiciel_libre_.C2.BB_et_.C2.AB_open_source_.C2.BB
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: tracing
Posté par Krunch (site web personnel) . En réponse au message la commande PS ne rend plus la main et vautre ma session. Évalué à 3.
strace et gdb vont sans doute pas t'en apprendre plus que « ça bloque dans l'appel système stat() » (ou peut-être un autre mais je mise une cacahouéte sur stat()). Par contre, un sysrq-t va te permettre de voir dans quoi ça coince au niveau noyau. Donc "echo t > /proc/sysrq-trigger" et tu nous dit ce que tu vois dans les logs noyau concernant ce ps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fragmentation
Posté par Krunch (site web personnel) . En réponse au message Problème d'OOM killer sur un NAS LaCie. Évalué à 2.
Bl0rgué avec un peu plus de détails : http://bl0rg.krunch.be/oom-frag.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: moi j'aime bien la machine "standard" de developpement
Posté par Krunch (site web personnel) . En réponse au journal Comment ça marche chez microsoft. Évalué à 3.
Si c'est pour compiler la version finale qui sera distribuée aux clients, oui. Si c'est pour faire un test de deux minutes d'un truc que t'es en train de développer dans ton coin, non.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# libgtop
Posté par Krunch (site web personnel) . En réponse au message Graphique CPU. Évalué à 5.
gnome-system-monitor utilise libgtop qui expose un API pour les informations que tu veux récupérer. Cet API est plus ou moins documenté sur http://library.gnome.org/devel/libgtop/stable/ Le code est sur http://git.gnome.org/browse/libgtop
En pratique ça va lire /proc
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# oldnewthing
Posté par Krunch (site web personnel) . En réponse au journal Comment ça marche chez microsoft. Évalué à 4.
Dans un autre style avec moins de typos, le blog de Raymond Chen est aussi fort intéressant pour avoir un aperçu de comment ça se passe à Redmont.
http://blogs.msdn.com/b/oldnewthing/archive/tags/microspeak/ http://blogs.msdn.com/b/oldnewthing/archive/2010/12/07/10101193.aspx [...]
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: moi j'aime bien la machine "standard" de developpement
Posté par Krunch (site web personnel) . En réponse au journal Comment ça marche chez microsoft. Évalué à 9.
Il dit aussi :
Donc, en principe ça n'empèche pas les tests fréquents sur des systèmes plus petits. Et personnellement, je trouve aussi qu'avoir une grosse bécane pour développer a plus de sens.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: c'est voulu
Posté par Krunch (site web personnel) . En réponse au journal Red Hat et les patchs: Un journal du vendredi publié samedi. Évalué à 2.
Je ne suggérais pas d'attaquer qui que ce soit en justice. Je faisais juste remarquer que Red Hat paie pas mal d'avocats spécialisés pour penser à ce genre de trucs et que je doute qu'ils aient fait une erreur aussi simple. N'étant pas avocat ou juriste moi même je ne vais pas essayer de détailler ton erreur mais le bon sens me dit que légalement, Red Hat est en conformité avec les licences des logiciels qu'ils redistribuent.
Et légalement ni ce message ni ce thread ne vaut rien évidemment.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Une piste ?
Posté par Krunch (site web personnel) . En réponse au journal Red Hat et les patchs: Un journal du vendredi publié samedi. Évalué à 3.
Ces liens peuvent avoir un intérêt pour tous les grands analystes économiques qui fréquentent DLFP :
http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux_derivatives#List_of_Red_Hat_Enterprise_Linux_derivatives http://en.wikipedia.org/wiki/Oracle_Enterprise_Linux
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: gestion bizarre/pourrie des interruptions
Posté par Krunch (site web personnel) . En réponse au message Gel du démarrage. Évalué à 2.
Il y a plein de façons possibles et ça arrive tout le temps.
Même si le vrai problème provient d'un périphèrique ou firmware/BIOS défectueux, le driver correspondant peut sans doute être modifié pour ne pas causer un gel du système lorsque le matériel se comporte mal (évidemment ça dépend de ce qui se passe exactement).
Va falloir apprendre à écrire des descriptions de bugs moins tordues alors.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.