neologix a écrit 346 commentaires

La charge c'est le nombre moyen de processus en attente du CPU ou d'entrées-sorties. Ca a beau être un super notebook ultra-fashion avec plein de RAM, le disque dur doit sûrement pas être terrible, donc je parierais sur un démon qui tourne en background et qui passe son temps à indexer le disque dur (purement au hasard, si ça se trouve c'est le CPU qui pose problème, mais dans ce cas un simple "top" suffit à trouver le coupable). Regarde la valeur de iowait (wa dans top). Si c'est élevé, c'est le disque. Pour trouver le coupable, regarde si tu n'as pas un processus qui est souvent dans l'état 'D', ou sinon il y a les grands moyens :
echo 1 > /proc/sys/vm/block_dump
Après avoir arrêté syslogd/klogd. Ca va te dumper dans les logs noyau les accès disque. Repasser à 0 après quelques secondes/minutes.
Ca c'était la réponse constructive, maintenant pour le troll je te conseille de laisser tomber Ubuntu et de mettre une vraie distribution à la place (c'est-à-dire qui ne nécessite pas un quad-core avec 4GB de RAM pour tourner), comme Debian.

@NeoX:
Rien n'empêche de pinger le serveur avant, c'est une ligne à ajouter
@scullder:
Il est possible de parser la sortie de inotifywait pour ne mettre à jour que le fichier qui a été modifié
Comme je l'ai dit, ce n'est qu'une proof-of-concept, ça peut largement être optimisé.
D'ailleurs il existe déjà un outil qui fait ça en fait : http://code.google.com/p/lsyncd/. Il est en C, et utilise le couple inotify+rsync.
Maintenant, si tu veux un truc qui tient vraiment la charge, il te reste comme tu l'as dit GlusterFS.

Soit tu pars sur une solution à base de système de fichier distribué, soit, si ton système n'est pas critique, je pense qu'on peut faire un truc utilisable avec à base d'inotify et rsync.
L'idée c'est que inotify monitore les modifications faites sur un répertoire, et dès qu'une modification est faite, rsync le synchronise avec les autres noeuds.
Un truc du genre, en shell (non testé) :


#!/bin/sh

DIR_TO_MONITOR="/home/foo"
NODES="toto tata tutu"
REMOTE_PATH=`dirname $DIR_TO_MONITOR`

SYNC_CMD="rsync -aqz --contimeout=3 --timeout=3"
MONITOR_CMD="inotifywait -mr"


$MONITOR_CMD $DIR_TO_MONITOR | while read; do
for node in $NODES; do
$SYNC_CMD $DIR_TO_MONITOR $node:/$REMOTE_PATH
done
done



Bon, c'est juste une illustration (rsync est appelé à chaque événement, tu pourrais lancer une instance par noeud en parallèle, etc), mais ça te donne une idée. Il existe peut-être même déjà des outils qui font ça...

Oui.
La dépêche est mal formulée :
Si un processus utilise la totalité de la mémoire lui ayant été alloué alors son score est de 1000 (et de 0 si il n'utilise rien).
Ce n'est pas la mémoire qui lui a été allouée, mais plutôt la mémoire disponible pour ce processus. Il faut bien noter que ça peut être différent de la mémoire totale disponible, selon le type de processus, son ajustement OOM, les politiques de limitation de la mémoire en place, etc.
La seule chose qui se rapproche de cette histoire de mémoire allouée, c'est qu'avant l'OOM utilisait la taille de la mémoire virtuelle du processus, alors que maintenant il utilise la somme de la mémoire résidente et de la swap, ce qui reflète mieux la mémoire qui peut être libérée (parce que la mémoire virtuelle contient entre autre les fichiers mappés en mémoire comme les libraries).

T'aurais pas l'IPv6 activé, non ?
ssh et aptitude doivent être compilés avec le support de l'IPv6, mais pas ping.

Dans un premier temps, je te conseille de nettoyer la ventilation de ton portable, pour enlever la poussière accumulée.
Ce n'est pas normal qu'il s'éteigne à cause d'une température trop élevée lors d'une utilisation normale (ou alors il a un gros problème de desgin...).

Tu es sûr de toi ?
Une variable statique va dans le segment data, ou dans le bss si elle n'est pas initialisée (du coup elle ne prend pas de place dans le binaire, mais la place est allouée lors du chargement en mémoire).
D'ailleurs je ne vois pas comment elle pourrait être allouée auto-magiquement à l'appel de la fonction (elle ne peut pas être stockée dans la pile, et il faudrait faire un appel à sbrk/mmap pour l'allouer dans le tas).

Pour faire passer des données d'un processus à l'autre, il n'y a pas forcément besoin de les copier puisque le kernel peut mapper la même page dans les deux processus.

L'IPC par mémoire partagée ça a été fait sur certains micro-noyaux (par exemple sur QNX).
Mais on ne gagne pas forcément beaucoup par rapport à des envois de message : par exemple L4 se débrouille pour mettre le message dans les registres quand il peut, et provoquer un changement de contexte direct vers le processus à qui le message est envoyé.
Ensuite, avec de la mémoire partagée, il faut quand même un mécanisme de synchronisation pour indiquer l'arrivée des données (alors les messages en eux-même servent de primitive de synchronisation, tu bloques sur le recv/send).
Aussi, je ne vois pas trop comment ça se passe quand tu as 10 processus qui peuvent se parler, et comment le noyau contrôle ce qui est échangé, ça doit devenir le bordel.
Enfin, un problème que je vois, c'est pour les micro-noyaux distribués (par exemple Amoeba), bah là pas de mémoire partagée.

En effet...
Mais dans le cas général je ne pense pas que ce soit possible.
Une analyse statique ne permettra pas de couvrir les cas où le nom/chemin de l'exécutable appelé dépend de la valeur d'une variable.
Quelques pistes tout de même :
- apparemment il existe une option -rpm-requires dans certaines versions de bash qui liste des dépendances (mais elle n'est pas exhaustive en partie pour les raisons évoquées plus haut)
- en utilisant un compilateur pour bash il doit y avoir moyen d'arriver à quelque chose à partir du code généré
- sinon il reste l'écriture d'un parseur ad-hoc, mais ça risque de ne pas être marrant (et il ne sera pas non plus exhaustif)

En tout cas c'est un problème intéressant ;-)

Il m'a zappé le script...
strace -f -e execve script.sh 2>&1 | cut -d "\"" -f2

Un truc du genre (non testé)
strace -f -e execve 2>&1 | cut -d "\"" -f2

Vous connaissez tous Brad Spengler, expert en sécurité, auteur de grsecurity, auteurs de plusieurs exploits.
Et bien récemment, un article sur LWN a évoqué un nouvel exploit dont il était l'auteur, mais cette fois c'est le délais de correction qui était souligné (près de 9 mois) : http://lwn.net/Articles/404043/
En lisant l'article, on a l'impression qu'il y a eu un raté dans la gestion du rapport de Brad :
Brad says that he first reported this problem in December, 2009, but got no response. More recently, he sent a note to Kees Cook, who posted a partial fix in response.

Mais en fait, dans les commentaires de l'article, on s'aperçoit que ce n'est pas aussi simple.
Greg Kroah-Hartman lui demande
Was this sent to the security contact for the kernel? I just searched
and could not find any notice sent to security@kernel.org from Brad
during that month.

If it was not sent there, where was it sent?

Ce à quoi Brad répond :
The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him.[...]With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.

Donc, Brad n'a pas soumis l'exploit à la mailing-liste chargée de la sécurité, et n'en a fait part à Ted Ts'o que parce qu'il le sentait réactif.

Encore pire, l'exploit avait déjà été corrigé dans grsec depuis un moment :
> I've also got two local DoS mm-related bugs to be fixed if you'd like to
> take a look at them. They exist in all 64bit kernels since 2.6.26 or
> so. The first is an easy fix (we've fixed it in grsec for some time),
> but the other one requires some more thinking and decision making (it's
> memory exhaustion that causes a complete lockup of the machine -- and
> the OOM killer is unaware of the memory because it's not
> associated/accounted for by any task).

Donc pour résumer, on a quelqu'un qui :
- rapporte des exploits quand ça lui chante
- ne les rapporte pas aux personnes concernées
- corrige les failles concernées dans dans grsec

Morale de l'histoire :
- Brad en a sûrement d'autre en réserves, qu'il réserve pour plus tard (à la Sergey Bubka)
- suivez les commits grsec, et vous verrez peut-être passer des patchs pour des failles non corrigées dans le noyau vanilla

Ca veut dire :
"Excusez-moi, mais j'avais toujours pensé que le Linux allemand s'écrivait avec un 'z'. Je plane un peu..."

Il fait allusion à son écriture de Suse avec un 'z' dans son commentaire précédent.

Par contre, mon analyse personnelle m'indique que si les entreprises et les particuliers et les associations et l'état (et les autres, mais je crois avoir fait le tour) payent les logiciels supplémentaires comme la loi les y obligent, cela risque fort de diminuer leurs recettes (donc finalement diminution de la fiscalité) et d'augmenter leurs coûts (donc diminution des emplois).

Tu crois vraiment qu'il y a beaucoup d'entreprises, d'associations et d'organismes gouvernementaux qui ont des logiciels "pirates" ? Tu penses vraiment que ça représente quelque chose face à la masse salariale ?

Et puis surtout s'ils fallait vraiment payer son anti-virus, son Windows et son Photoshop... vous devinez la suite.

Ben oui il faut le payer. Si tu ne veux pas payer, tu peux te tourner vers des logiciels équivalents libres ou gratuits.

Je ne dis pas que les chiffres annoncés sont juste, je dis juste que que je ne comprends pas ce que tu essaies de démontrer (la contrefaçon de logiciels c'est mal, comme la contrefaçon d'oeuvres musicales/cinématographiques/artistiques).

Mais seulement le premier champ ($1) et le deuxième champ ($2).
Essaie avec awk '$0 !~ /pattern1/ && $0 !~ /pattern2/ '.
Il vaudrait d'ailleurs mieux faire un awk '$0 !~ /pattern1|pattern2/ ' ou encore un grep -v "pattern1|pattern2" ce sera plus rapide.

Oui, c'est compliqué, mais on peut imaginer qu'ils intègrent ça au mouchard Hadopi : contrôle à la source, pas de problème de charge, de single point of failure...
Parce que bon, pourquoi se contenter d'espionner le trafic quand on peut le bloquer ?

C'est la seule faute d'orthographe que tu as trouvé dans son journal ?

Trouvée, pas trouvé (COD antéposé).
Non, ce n'est pas la seule, mais c'est une faute relativement courante.

Le Jailbreak est la voix rêvée pour installer un rootkit qui viendra enrichir un réseau de machine zombie.

Voie, pas voix.

Je ne connais pas Tomcat, mais je suis curieux de voir ce que donne RPS+RFS avec par exemple vsftpd (qui sous Linux utilise sendfile)...

Oui cela existe, c'est supporté par NAPI :
http://www.linuxfoundation.org/collaborate/workgroups/networ(...)

Ce n'est pas seulement utile en cas de DOS, il suffit d'avoir quelques cartes 1Gb/s et pas mal de trafic, cela fait déjà un certain nombre d'interruptions.
D'ailleurs, ce principe d'"interrupt mitigation" va peut-être faire son apparition pour les disques, avec l'apparition des SSD :
http://lwn.net/Articles/346219/

Le truc, c'est que si les gens arrêtaient d'accepter des salaires minables, peut-être que les salaires augmenteraient. Quand je vois les salaires d'ingénieurs/chercheurs en France, j'ai envie de pleurer.

Si un fichier est modifié pendant l'appel de latexmk, inotifywait va bloquer à l'itération suivante, et donc tes fichiers pdf ne seront pas mis à jour (jusqu'à la prochaine modification).
Juste en passant.

Il va vite être dégueulasse l'écran...

Et ?
Il ne faut pas s'étonner d'avoir des gens qui se voient refuser l'accès aux bureaux de vote lorsqu'on fait cela en semaine, étant donné que la plupart des gens travaillent, et ont d'autres obligations après le travail (enfants par exemple). Maintenant si tu veux, on pourra organiser la prochaine élection présidentielle un jeudi en plein mois d'août...
Je n'ai jamais prétendu que le système français est parfait (pour ton information, il y a une distinction entre esprit critique et chauvinisme), mais puisque tu y tiens, le résultat des élections a montré à quel point leur système est au point...

Il faut vraiment le faire exprès pour programmer une élection un jeudi, surtout pour un scrutin aussi important.
Je pense que l'on devrait faire la même chose en France, pour être sûr de passer la barre des 70% d'abstention...