Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

**snipx** · 17/11/2017, 16h56

Envoyé par gbip

Coin !
Je cherche des infos sur OpenBSD (et BSD en général), notamment sur l'ordonnancement, la gestion des processus et la gestion de la mémoire.
Outre la page wikipédia, vous avez des présentations/cours/article sur le sujet ?
Merci d'avance !

Le code source ? :D

Blague à part, tu peux peut-être trouver des réponses à tes questions sur cette page : http://www.openbsd.org/events.html

Exemple de prez sur la mémoire : http://www.openbsd.org/papers/tdose_...sentation.html

**TarteAuxFleurs** · 17/11/2017, 16h59

Envoyé par snipx

Le code source ? :D

Blague à part, tu peux peut-être trouver des réponses à tes questions sur cette page : http://www.openbsd.org/events.html

Exemple de prez sur la mémoire : http://www.openbsd.org/papers/tdose_...sentation.html

Ah ouais, bien vu

Merci !

**Mayalabielle** · 17/11/2017, 18h40

Envoyé par gbip

Tu les as trouvé où les versions haute définition ?

https://www.openbsdstore.com/cgi-bin...ate=department

**Møgluglu** · 23/11/2017, 16h43

J'ai un problème de swap sur ma machine sous Fedora 24, noyau 4.11.
J'ai 16 Go de RAM et 8 Go de swap sur un SSD. Sauf que Linux ne touche quasiment pas au swap, et une fois que les 16 Go sont pleins, bah le système freeze.

Et l'OOM killer est devenu un hippie pacifiste dans les Linux modernes.

Un peu avant le freeze j'ai ça :

Code:

> top
KiB Mem : 16310076 total,   210340 free, 13599588 used,  2500148 buff/cache
KiB Swap:  8193020 total,  7998004 free,   195016 used.   524836 avail Mem 

> cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/sda2                               partition	8193020	175560	-1

Une idée d'où ça peut venir et qu'est-ce que je dois regarder ? La prio du swap est à -1, mais c'est la valeur par défaut depuis Linux 1.3 au moins, donc si ça posait problème je pense que ça se saurait.

**Wobak** · 23/11/2017, 17h01

Quand tu dis que le PC freeze tu as un crash dump ?

Ou c'est juste des freezes qui se relâchent dès que la RAM redevient dispo ?

**Cwningen** · 23/11/2017, 17h05

"sysctl vm.swappiness" plus c'est bas, plus le swap est utilisé tardivement.

**Møgluglu** · 23/11/2017, 23h12

Envoyé par Wobak

Quand tu dis que le PC freeze tu as un crash dump ?

Ou c'est juste des freezes qui se relâchent dès que la RAM redevient dispo ?

La deux. Mais je n'ai pas toujours la patience d'attendre des plombes surtout que j'ai autre chose à faire que d'attendre d'avoir un terminal pour pouvoir lancer un kill.

Envoyé par Cwningen

"sysctl vm.swappiness" plus c'est bas, plus le swap est utilisé tardivement.

Merci, c'est bien ça !

> sysctl vm.swappiness
vm.swappiness = 1
> sysctl vm.min_free_kbytes
vm.min_free_kbytes = 67584

Ce qui revient à quasiment désactiver le swap.
Apparemment un admin bien intentionné avait changé la valeur par défaut dans le sysctl.conf.

**moimadmax** · 03/12/2017, 10h12

Bonjour,
J'ai un problème sur mon raspberrypi mais je pense que c'est fortement lié à Debian :

Code:

root@raspberrypi:/home/matthieu# apt-get update
Atteint:2 http://mirrordirector.raspbian.org/raspbian stretch InRelease
Réception de:1 http://archive.raspberrypi.org/debian stretch InRelease [25,3 kB]
Lecture des listes de paquets... Fait                          
E: Repository 'http://archive.raspberrypi.org/debian stretch InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
root@raspberrypi:/home/matthieu#

ça vient du dépot de raspi.list pour le nouvel UI, ou il n'y a pas encore de dépot testing.

Je comprend bien que c'est parce que stretch est passé de testing a stable, et qu'il faut l'accepter, mais comment, ça j'ai pas trouvé. J'ai pourtant tenter:
- Mettre à jour le raspi.list (en me disant qu'il allait refaire l'authentification)
- apt-key net-update
- apt-get update --allow-releaseinfo-changes
- puis un appel à google avec le message d'erreur et "debian how to accept suite change"

Puis me voilà ici.
Je sens que c'est un truc à la con en plus.
Merci

**Cwningen** · 03/12/2017, 11h40

"man 8 apt-secure" n'aide pas ? (je ne suis pas sous debian, je ne sais pas à quoi la page ressemble.)

**Mayalabielle** · 03/12/2017, 12h08

Paste ton fichier list stp

**moimadmax** · 03/12/2017, 12h56

Voilà : le raspi.list est pour leur nouvel ui il me semble.

Code:

matthieu@raspberrypi:/etc/apt $ cat sources.list
deb http://mirrordirector.raspbian.org/raspbian/ stretch main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspbian.org/raspbian/ jessie main contrib non-free rpi

matthieu@raspberrypi:/etc/apt $ cat sources.list.d/raspi.list 
deb http://archive.raspberrypi.org/debian/ stretch main ui
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ jessie main ui

matthieu@raspberrypi:/etc/apt $

et le man apt-secure : http://manpages.ubuntu.com/manpages/...-secure.8.html

**moimadmax** · 04/12/2017, 22h04

Bon après avoir téléchargé les sources et fouillé un peu, il fallait juste faire apt-get update allow-releaseinfo-change-suite
Il y a une typo dans le man avec un ajout de S a change.
Du coup c'est réglé.

**Tilt** · 10/12/2017, 20h29

Ce week end j'ai trouvé deux bonnes applis.
"Redshift" facile à configurer avec l'applet cinnamon ! (filtre anti lumière bleue et changement de luminosité la nuit)
"Molotov", la tnt en streaming sur son pc ! (ne marche qu'en France y compris l'outre mer)

**William Vaurien** · 11/12/2017, 16h47

Petit casse tête pour admin Linux chevronné.

Sur un des logiciels que je maintiens nous utilisons un framework web antédiluvient. Le tout est écrit en C. Nous venons de migrer de Solaris à Linux et depuis le passage en prod nous avons des erreurs côté serveur non visible par les users. Nous appelerons par la suite le framework 'vieux_truc_moisi' et notre application 'superApp2000'. VieuxTrucMoisi est une boite noire et je n'ai pas le code...

La chaine d'appel est grosso modo: browser -> apache -> cgi-bin -> 'vieux_truc_moisi' -> 'superApp2000'

Notre système est un vieux Red-Hat Enterprise 6 et les coredumps sont convenablement configuré. Si j'appel un cgi-bin qui fait un coredump, j'ai le coredump où je l'attend.
Si j'appel un binaire qui fait un coredump, idem.
Si je fait un kill -11 d'un truc, par example httpd, idem.

Par contre quand superApp2000 se vautre, il y a un petit log dans le error apache qui dit "Premature end of script headers: vieux_truc_moisi". Et pas de coredump. Nul part. Aucune trace. Même pas un petit log dans /var/log.
Et c'est très ennuyeux, parce que comme il n'y a apparemment pas d'impact pour les utilisateurs, je n'ai aucune idée de comment retrouver l'origine du problème...

Le support de 'vieux-truc-moisi' me garantie que son framework ne fait rien de spécial et qu'il ne trappe pas les erreurs... Mais j'ai comme un doute.

Est-ce qu'il y a un moyen de forcer le coredump de vieux-truc-moisi ou de superApp2000 ?

Quand j'attache un debugger au pid de superApp2000, je vois bien qu'il y a un crash, mais aucun coredump n'est généré. Pour le système tout va bien.

Code:

Program received signal SIGSEGV, Segmentation fault.
0x000000000061e42c in MaFonctionQuiPlante (requete=2, fonction=0) at MaFonctionQuiPlante.c:21332
21332     char tomcatServerName [128+1];
(gdb) bt
#0  0x000000000061e42c in MaFonctionQuiPlante(requete=2, fonction=0) at MaFonctionQuiPlante.c:21332
#1  0x000000000040a5c6 in DoGetRequete (screenName=0x5356200 "DansTaFace", flags=0) at MaFonctionQuiPlante...
... stack de vieux_truc_moisi
#22 0x00000000004087fe in start_up (argc=2, argv=0x7ffc77833f68) at superApp2000.c:3616
#23 0x00000000004085cc in main (argc=2, argv=0x7ffc77833f68) at superApp2000.c:3526

J'ai essayé une flopée de suggestions trouvées sur SO et autres Super User, rien ne marche et comme déjà dit les core dumps fonctionnent très bien partout ailleurs...
Je suis preneur de toute suggestion: je suis un peu désespéré là: j'ai besoin de ces coredumps !

**Wobak** · 11/12/2017, 18h17

Quand tu dis boite noire, ça veut dire quoi ? C'est un binaire compilé ?

Tu peux imiter le contenu des appels de httpd pour trigger le problème ?

Est-ce que tu peux essayer de capturer les ressources utilisés par le vieux truc à intervalles réguliers ? histoire de comprendre s'il ne saturerait pas ses ressources ?

**Exosta** · 11/12/2017, 18h26

Je connais pas très bien Red Hat 6 donc ça peut ne pas fonctionner mais quel est le résultat de ces commandes ?

Code:

cat /proc/sys/kernel/core_pattern
cat /proc/$(pidof superApp2000)/limits

Et je comprends pas bien un truc : si tu as le backtrace de ton crash, qu'est-ce qui t'empêche de générer un coredump depuis gdb ?

**William Vaurien** · 12/12/2017, 09h22

Alors le problème c'était ... roulement de tambour ... Oracle.
Oui oui, la boite noire utilise une connection Oracle. Avec du pro*c dedans (techno des années 90).
Et ce con d'Oracle vient poser des handlers de signaux, dont le comportement est en plus différent suivant les OS.

Sur Linux il se contente de sortir avec un code 1 sans repasser la main au système. D'où l’absence de tout core.

Voir ce beau post su SO: https://stackoverflow.com/questions/...ds-why-and-how

Je peux faire une backtrace depuis gdb en simulant l'erreur dans le code, mais que les problèmes se produisent de manière erratique, en prod seulement et sans conséquence visible pour les utilisateurs.
Donc en gros le programme sort comme une fleur au milieu d'un truc, et j'ai juste une petite ligne dans les logs apaches pour me dire que le cgi-bin c'est vautré...

Maintenant je vais pouvoir virer le flag de diagnostique Oracle et récupérer les coredump et de trouver la source du problème.

edit: en fait en suivant la doc c'est juste que par défaut (soit mon IT soit Oracle tout seul) le système de diagnostique Oracle est en route, mais que le répertoire configuré n'existe pas et que le driver d'Oracle cache ce fait et ne cherche pas à trouver une autre destination adaptée, à la place il fait tout disparaître...

edit2: Oracle installe ses hooks pour diagnostiquer des erreurs qui pourraient se produire lors d'un appel à la base. Très bien. Mais ce Connard ne les enlève pas une fois l'opération effectuée.
Donc le système de diagnostique siphonne tous les problèmes, même ceux qui ne le concerne pas, et ne prévient pas s'il ne peur rien faire avec.

**Paradox** · 12/12/2017, 15h03

Sans vouloir jouer au fanboy, ca m'aurait etonne que ca soit de la faute de Linux.

Pire, ca m'aurait etonne que ce soit pas de la faute d'Oracle ; disons qu'ils font partis du top 10 des choix "discutables".

**Wobak** · 12/12/2017, 16h04

Envoyé par Møgluglu

La deux. Mais je n'ai pas toujours la patience d'attendre des plombes surtout que j'ai autre chose à faire que d'attendre d'avoir un terminal pour pouvoir lancer un kill.

Merci, c'est bien ça !

Ce qui revient à quasiment désactiver le swap.
Apparemment un admin bien intentionné avait changé la valeur par défaut dans le sysctl.conf.

Tiens je reviens là dessus puisque j'apprends ça en ce moment, donc je complète pour ceux que ça pourrait intéresser (oui je me fais un mémo pour mes révisions si je veux

)

swap_tendency = mapped_ratio/2 + distress + vm_swappiness

où mapped_ratio = % de la mémoire physique actuellement utilisé, et distress c'est une valeur qui s'incrémente de 0 à 100 en fonction du nombres d'essais faits pour libérer de la mémoire et réussir.

Si on a la tendency à 100 ou plus, on swap, sinon on libère une page du cache.

Mettre la vm_swappiness à 0 revient à désactiver la swap sur la plupart des systèmes. 1 est donc la plus petite valeur possible.

Si avec 1 et les autres valeurs réglées tu avais la tendency toujours en dessous de 100, la machine essayait de ne jamais swap, ce qui explique bien le comportement que tu avais, qui devait peut être attendre que la distress atteigne 49/50 avant de réussir à libérer la machine en swappant correctement.

**William Vaurien** · 12/12/2017, 16h27

Envoyé par Paradox

Sans vouloir jouer au fanboy, ca m'aurait etonne que ca soit de la faute de Linux.

Pire, ca m'aurait etonne que ce soit pas de la faute d'Oracle ; disons qu'ils font partis du top 10 des choix "discutables".

Oui, Oracle est discutable, mais bon il est là depuis des décennies comme base de données, c'est parfois trop compliqué (ou coûteux ou les 2) de changer...

Par contre sans vouloir faire de l'anti fanboy, RedHat est un peu pourri en ce qui concerne les coredumps: de base ils ne sont pas activés, il faut faire pas mal de manip pour les mettre en marche et sur deux niveaux: le niveau Linux traditionnel et le système abrt spécifique à RehHat... Au début suite à une mauvaise configuration de ce dernier les cordump étaient allègrement effacés du système juste après avoir été générés

Donc tout n'est pas si rose dans le monde des pingouins...
Et en plus quand on voit la merde causé par toutes les micro-incompatibilités entre toutes ces distributions consanguines, j'aimerais presque avoir mes serveurs sous windows...

**Wobak** · 12/12/2017, 16h31

Envoyé par William Vaurien

Oui, Oracle est discutable, mais bon il est là depuis des décennies comme base de données, c'est parfois trop compliqué (ou coûteux ou les 2) de changer...

Par contre sans vouloir faire de l'anti fanboy, RedHat est un peu pourri en ce qui concerne les coredumps: de base ils ne sont pas activés, il faut faire pas mal de manip pour les mettre en marche et sur deux niveaux: le niveau Linux traditionnel et le système abrt spécifique à RehHat... Au début suite à une mauvaise configuration de ce dernier les cordump étaient allègrement effacés du système juste après avoir été générés

Donc tout n'est pas si rose dans le monde des pingouins...
Et en plus quand on voit la merde causé par toutes les micro-incompatibilités entre toutes ces distributions consanguines, j'aimerais presque avoir mes serveurs sous windows...

Ça dépend si c'est du coredump kernel ou process en fait non ?

**Møgluglu** · 12/12/2017, 16h31

Envoyé par Wobak

swap_tendency = mapped_ratio/2 + distress + vm_swappiness

Merci pour l'explication !
Effectivement, ça explique pourquoi ma détresse monte à 50 avant celle de Linux.

Depuis que j'ai remis la swappiness à 60, ça se comporte comme je l'attends : il commence à swapper tranquillou à 80% de mapped_ratio et évite de trop pourrir le cache.

**Tramb** · 12/12/2017, 16h36

Envoyé par William Vaurien

Oui, Oracle est discutable, mais bon il est là depuis des décennies comme base de données, c'est parfois trop compliqué (ou coûteux ou les 2) de changer...

Par contre sans vouloir faire de l'anti fanboy, RedHat est un peu pourri en ce qui concerne les coredumps: de base ils ne sont pas activés, il faut faire pas mal de manip pour les mettre en marche et sur deux niveaux: le niveau Linux traditionnel et le système abrt spécifique à RehHat... Au début suite à une mauvaise configuration de ce dernier les cordump étaient allègrement effacés du système juste après avoir été générés

Donc tout n'est pas si rose dans le monde des pingouins...
Et en plus quand on voit la merde causé par toutes les micro-incompatibilités entre toutes ces distributions consanguines, j'aimerais presque avoir mes serveurs sous windows...

D'un autre côté c'est pas évident/automatique qu'un système en prod doit dumper des core à chaque crash.

**William Vaurien** · 12/12/2017, 16h42

je sais pas, j'ai du trop faire de Java: une merde, une stack.
C'est simple et efficace, et comme ça tu ne passes pas des heures a trouver l'origine du problème...

Quel est l’intérêt de planquer/supprimer les core ?

**Cwningen** · 12/12/2017, 16h48

Un core c'est plus gros qu'une trace de pile puisque ça contient toute la mémoire du processus crashé. Ça risque de remplir rapidement le disque de l'utilisateur qui n'est pas au courant de ces core.

**Wobak** · 12/12/2017, 16h55

Il m'a fallu 20 secondes pour traduire "trace de pile" en "stacktrace"

**Paradox** · 12/12/2017, 17h05

Envoyé par William Vaurien

Oui, Oracle est discutable, mais bon il est là depuis des décennies comme base de données, c'est parfois trop compliqué (ou coûteux ou les 2) de changer...

L'eternelle justification. Sauf qu'un jour, il faudra bien le faire. #dettetechnique

Envoyé par William Vaurien

Par contre sans vouloir faire de l'anti fanboy, RedHat est un peu pourri en ce qui concerne les coredumps: de base ils ne sont pas activés, il faut faire pas mal de manip pour les mettre en marche et sur deux niveaux: le niveau Linux traditionnel et le système abrt spécifique à RehHat... Au début suite à une mauvaise configuration de ce dernier les cordump étaient allègrement effacés du système juste après avoir été générés

Donc tout n'est pas si rose dans le monde des pingouins...
Et en plus quand on voit la merde causé par toutes les micro-incompatibilités entre toutes ces distributions consanguines, j'aimerais presque avoir mes serveurs sous windows...

Ah, non, j'ai jamais dis que le monde etait tout rose au pays des pingouins ; mais il faut aussi comprendre que RHEL est une version un peu particuliere car (presque la seule) venant avec un support et que c'est plus ou moins la seule chose qui soit vendue. J'ai eu l'occasion de voir de trucs tellement bizarres UNIQUEMENT sur RHEL, qu'on avait dit avec les confreres que c'etait pour faire marcher le support plutot que de l'incompetence au vu des problemes. Donc tout ce qui est RHEL-specific, je ne le considere meme plus.

(J'ai bien conscience que Canonical essaye de faire pareil avec Ubuntu Server, mais je ne peux decemment pas les mettre dans la meme categorie.)

Sans compter les proces lies a l'utilisation de Java (et oui, Java n'est pas necessairement gratuit !), qu'Oracle mene maintenant comme une croisade.

Mais sinon, faut vouloir avoir des ennuis pour vouloir ses serveurs sous Windows...

**William Vaurien** · 12/12/2017, 17h05

Dans ce cas pourquoi ne pas garder que le strict nécessaire au diagnostic ? Pour moi (dev) c'est une aberration... j'imagine que les admins ont tout un tas de bonnes raisons.

**Tramb** · 12/12/2017, 17h52

Bah par exemple, ton programme peut avoir un handler d'exception/signaux qui printe juste la backtrace dans les logs et/ou dumpe le core a un endroit particulier avec des settings particuliers.
Ca a l'air d'être l'optique de Oracle qui ne veut pas dépendre (je joue à la devinette) de la config du système.
Pense à ces programmes qui te font une boîte de dialogue custom quand ils crashent et qui te proposent d'envoyer un dump ou une stack par le réseau .

Moi je ne fais jamais de bugs, donc la question ne se pose que rarement.

**Askulmin** · 13/12/2017, 11h56

Salut les canard, j'ai monter mon NAS maison, et je découvre avec joie les script que l'on peut créer pour utiliser au mieux celui-ci.
Avez vous une amélioration a proposer pour cette formulation :

Code:

cd $SRC
	mv * $DEST_FIN
	echo "Déplacement après convertion : OK"

Code complet :

Spoiler Alert!

Discussion: Le fil des beaux gosses linuxiens, v2 où comment installer LFS sur BTRFS en RAID10

Outils de la discussion

Règles de messages