|
|
Le 06-06-2020, Nicolas George <nicolas$george> a écrit :
> Je te laisse me dire : est-ce qu'un bug de systemd a cassé screen, ou bien > est-ce que des gens ne lisent pas la doc ? J'avais dit dès le début que je n'avais pas lu la doc sur ce truc en particulier, donc pour ça je fais partie des gens qui ne lisent pas la doc, mais je n'avais pas d'avis non plus. Maintenant que je vois la partie indiquée, ça me semble plutôt pas mal. Tu peux demander à tuer tous tes process par défaut. Et en cas de besoin particulier, tu lances expressément un process qui ne sera pas tué. |
|
|
|
Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit :
> Pour fixer les idées : > [..] 1224 open, 5016 closed. Sauf que dans la liste il y a des choses qui vont du bug à la demande d'amélioration, en passant par des questions limite forum (du type "je ne vois pas comment faire ça", sans que ça ait forcément (encore) été trié comme demande d'amélioration) Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed. Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi quand même... > Soyons joueur... > Configuration : i7, 32 Go de mémoire. Heureusement qu'il y a 32 > Go de mémoire parce que, je viens de vérifier, le processus de PID > 1 consomme 170,6 Mo de mémoire. Et il n'est même pas verrouillé > en mémoire ! Chez moi aussi, sauf que top dit ça : VIRT : 175288 RES : 5292 %MEM : 0,0 Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo de mémoire réservée. Ce qui peut aussi bien signifier que plein de code est associé à la mémoire virtuelle du processus mais que ce n'est pas forcément chargé en mémoire. Par "verrouillé en mémoire", tu veux dire que le code devrait rester en mémoire en permanence ? Auquel cas j'imagine que c'est moins intéressant s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système d'initialisation qui ne sert jamais reste en mémoire est plus pertinent que pour n'importe quel processus ? > Depuis le 13 mai, on se demande ce qu'il a fait en consommant > 1h04 de temps CPU. > Sur mon serveur (NetBSD 9.0) qui a redémarré le 21 mai dernier, > init a consommé 27,01 s de temps CPU et occupe 19 Mo. Il y a > beaucoup plus de choses lancées sur le BSD que sur mon poste > client (qui utilise Windowmaker si on veut être précis). Pareil ici, mais ça représente environ 2 minutes par jour. Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple systemd gère des journaux, le temps de traitement lui est sans doute attribué. |
|
|
Le 06-06-2020, JKB <jkb> a écrit :
> Le 06 Jun 2020 10:41:26 GMT, > Stéphane CARPENTIER <sc> écrivait : > Il y a plein de choses qui peuvent marcher. Ce qui rate peut aussi > marcher de temps en temps. C'est assez shadokien comme logique. > Pour fixer les idées : > [..] > 1224 open, 5016 closed. Là, tu vas dans mon sens. D'abord, c'est pas une liste de bugs, c'est une liste de tâches. Il y a un bug reconnu comme tel. Il y a des demandes d'évolutions. Il y a des gens un peu paumés (ce que je comprends mon sens n'est pas de dire que systemd est d'une simplicité enfantine). Sur la première page, il y a 25 demandes. Dont 9 demandes d'évolutions. Il y a un bug recensé comme tel. Il y a deux demandes d'attentes d'explications utilisateurs. En gros, sur une application stable avec un nombre conséquent d'utilisateurs, tu peux t'attendre à 1 bug pour 10 demandes de support. Pour ce que j'en vois on en est très loin (si je regarde la seconde page, je ne vois qu'un bug et qu'une régression). Les applications moisies que j'ai pu voir, je t'assure que c'est vraiment pas le même ratio. Donc, oui, vu la cabale sur systemd, s'il y avait une foule d'utilisateur hurlante, elle m'aurait été pointée. > Je te conseille de lire les premiers, il y en a des croquignolets et > on se demande même comment ça peut fonctionner sur un poste de > travail Le premier qui demande comment faire pour que son laptop puisse se mettre en veille s'il est débranché mais pas s'il est branché et que ça doit aussi dépendre de s'il est connecté à un moniteur partagé avec un autre ordinateur n'est quand même pas un truc banal. > (le coup des baux DHCP est amusant, enfin peut-être, faut > juste ne pas être concerné !). Ce qui est important, c'est pas qu'il y ait des anomalies, c'est que ce soit vitre traité. Et là, c'est traité en une dizaine de jours, c'est pas mal. > Ça aussi, c'est éloquent : > [..] Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de conf, c'est debian qui intègre mal le package : c'est pas de la faute de systemd. > Ah non, je n'utilise plus de distribution grand public depuis que > systemd a montré le bout de son nez. Je taille aujourd'hui des BSD à > la serpe. Bien plus efficaces. Et lorsque ce n'est pas supporté par > NetBSD, je n'utilise plus les architectures en question. J'ai eu > beaucoup trop de problème avec le CPU magique à tout faire qui est > vaguement supporté par une équipe chez un fondeur. Et bien c'est super alors. > Le problème, c'est que tu veux absolument voir le problème par le > petit bout de la lorgnette. Les problèmes que l'on rencontre dans > l'embarqués sont identiques sur des réseaux par design (parce que > systemd est mal conçu dès le départ). Tu veux dire que si le F5 c'est un bordel immonde que personne ne maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du boulot, lorsque je vais sur une application Extranet, si ça rame en traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais entendu de critique de systemd comme source. Le réseau du boulot est tellement pourri que pour aller sur certaines applications sur l'Extranet il vaut mieux utiliser son ordinateur personnel. Alors, oui, je sais, l'architecture c'est super important. Je m'engueule assez souvent avec des architectes et des gens de la sécurité pour savoir quelles sont les contraintes. Et c'est marrant, mais systemd, c'est jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que j'ai découvert ça. Quand les architectes me proposent une solution, plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en ligne de compte : ils s'en cognent. >> Ce que je sais, c'est qu'au boulot, les problèmes que nous avons avec >> les serveurs, il y en a et ce n'est pas sur systemd que les gens râlent. > Je n'ai jamais dit que ça ne fonctionnait pas dans certains cas, je > prétends que c'est une catastrophe industrielle et un nid à emmerdes > sans nom. Je prétends qu'on passe beaucoup plus de temps à avoir une > configuration à peu près fiable avec systemd qu'avec un init de type > SysV ou BSD. Je ne te parle pas de juste des cas particuliers qui tombent en marche par chance. Je te dis que pour ce que je vois, systemd ne pose pas de problème. Je travaille à la DSI d'une grosse entreprise. Je sais ce qui pose problème sur nos applications. Parce que les gros problèmes j'en entend parler. Si systemd faisait partie du TOP 100 des sujets, j'en aurais forcément entendu parler à un moment où à un autre. Ça ne veut pas dire qu'il n'y a aucun problème avec systemd, ça veut dire qu'ils ne sont pas assez importants pour remonter. Et c'est vraiment loin d'être la guerre que tu me décris. Au boulot, le deuxième plus gros problème (après le réseau), c'est l'obsolescence. Et encore, maintenant que tout est virtualisé, nous n'avons plus le risque qu'il y avait il y a dix ans de devoir faire les puces si certaines machines tombaient. Au boulot, l'un des très gros sujet vient des interfaces entre les systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité de sécurité, de plein de trucs. Au boulot, un autre sujet sensible vient à la fois de la sensibilité des informations pour savoir quelle sécurité appliquer dessus ainsi que la loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que légal que technique. Le problème d'Oracle qui se met à faire payer java, par exemple, c'est un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur tous les serveurs. Le sujet de dégager les Windows 2003 qui continuent à trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à trainer c'est un vrai sujet. Le sujet des applications mal codées qui coûtent une fortune en maintenance, c'est un vrai sujet. Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc. Que ce soit pour des sauvegardes. Que ce soit pour des applications sur le DRP, pour des applications sur le cloud, pour des applications sur dans les centres de services. Pour des petites applications ou des gros ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je vais te dire que des sujets j'en ai vu passer. |
|
|
Le 06-06-2020, Yliur <yliur> a écrit :
> brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi > quand même... Oui, mais il a le droit ici. C'est le forum de la mauvaise foi. Ça ne peut pas lui être reproché. |
|
|
Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC),
Yliur <yliur> écrivait : > Le Sat, 06 Jun 2020 12:34:07 +0000, JKB a écrit : > d'amélioration, en passant par des questions limite forum (du type "je ne > vois pas comment faire ça", sans que ça ait forcément (encore) été trié > comme demande d'amélioration) > Si on ne considère que l'étiquette "bug", on a ça : 89 open, 829 closed. > Il se peut qu'en réalité ce soit un peu plus, mais prendre le chiffre > brut sans même regarder ce qu'il y a dedans c'est de la mauvaise foi > quand même... Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui devrait être trivial et entièrement prouvé (parce que c'est tout de même sur lui que repose la stabilité du système). > Chez moi aussi, sauf que top dit ça : > VIRT : 175288 > RES : 5292 > %MEM : 0,0 > Donc si je comprends bien, 170Mo de mémoire virtuelle mais seulement 5Mo > de mémoire réservée. Ce qui peut aussi bien signifier que plein de code > est associé à la mémoire virtuelle du processus mais que ce n'est pas > forcément chargé en mémoire. Ça veut surtout dire virtuelle et résidente à l'instant /t/. Il y a 170 Mo de mémoire réservée quelque part (allocations mémoire, bibliothèques partagées le cas échéant) qui consomment des ressources. > Par "verrouillé en mémoire", tu veux dire que le code devrait rester en > mémoire en permanence ? Oui. mlock est fait pour cela. Il y a des cas où systemd file dans le swap et le résultat est... intéressant ! > Auquel cas j'imagine que c'est moins intéressant > s'il y en a beaucoup. Mais pourquoi le fait qu'un bout de code du système > d'initialisation qui ne sert jamais reste en mémoire est plus pertinent > que pour n'importe quel processus ? Parce que init doit récupérer tout un tas de choses dont les codes de retour de tous les processus sous peine d'avoir des zombies. Pour mémoire, un zombie, c'est un processus dont le père ou init n'est pas allé à l'enterrement. Si à chaque fois qu'un processus lancé par init s'achève, que init est dans le swap et que ton système va chercher les pages dans le swap pour simplement lire la valeur de retour du fils, je pense que tu vas assez rapidement t'énerver. Et c'est assez vite le cas sous Linux depuis quelques noyaux, la valeur de vm.swapiness ne servant quasiment plus à rien. Le noyau, dans sa majorité, doit rester en mémoire (le noyau Linux sauf si cela a changé depuis que j'ai arrêté de tripatouillé à l'intérieur, est totalement verrouillé en mémoire). Pour des raisons de performances, il est bon que le PID 1 y reste aussi. > Pareil ici, mais ça représente environ 2 minutes par jour. > Ta comparaison avec NetBSD, c'est à périmètre équivalent ? Par exemple > systemd gère des journaux, le temps de traitement lui est sans doute > attribué. Tiens parlons-en. Le fait que les journaux soient sous forme binaire est un autre truc inacceptable. Malgré le fait que NetBSD écrit des lignes et des lignes en raison d'un client NFS de FreeBSD problématique (lockd), le temps CPU utilisé par syslog n'arrive pas à la cheville de celui utilisé par systemd. JKB |
|
|
Le 06-06-2020, JKB <jkb> a écrit :
> Le Sat, 6 Jun 2020 13:58:28 -0000 (UTC), > Même s'il n'y en a _que_ 1000, ça fait beaucoup pour un daemon qui > devrait être trivial et entièrement prouvé (parce que c'est tout de > même sur lui que repose la stabilité du système). Pas forcément, ça dépend autant de leur sévérité et de leur temps de traitement. Si tu fais du déploiement par lot, oui, il faut beaucoup tester avant chaque livraison. Mais si tu fais du développement continu, tu ne t'inquiètes pas trop des problèmes mineurs car c'est facile de revenir en arrière. |
|
|
Le 06 Jun 2020 14:58:49 GMT,
Stéphane CARPENTIER <sc> écrivait : > Le 06-06-2020, JKB <jkb> a écrit : >> Ça aussi, c'est éloquent : >> [..] > Oui, ben qu'une testing ne soit pas stable, c'est prévu. C'est pour ça > que ça s'appelle testing. Pour moi, quand il ne trouve pas un fichier de > conf, c'est debian qui intègre mal le package : c'est pas de la faute de > systemd. La liste des bugs est la liste historique du paquet quelle que soit la distribution. Il n'y a pas de notion de unstable dans les bugs retournés. > Tu veux dire que si le F5 c'est un bordel immonde que personne ne > maîtrise c'est à cause de systemd ? Tu veux dire que sur mon poste du > boulot, lorsque je vais sur une application Extranet, si ça rame en > traversant 3 routeurs, 5 firewall et 2 F5 c'est à cause de systemd ? On > a des problèmes de réseau super compliqués indémerdable. Je n'ai jamais > entendu de critique de systemd comme source. Le réseau du boulot est > tellement pourri que pour aller sur certaines applications sur > l'Extranet il vaut mieux utiliser son ordinateur personnel. Le problème de systemd, c'est qu'il est foutu de ne pas démarrer correctement les interfaces réseau dans l'ordre, voire de les renommer. Les résultats peuvent être... intéressants. Ça va du serveur injoignable à des services qui plantent au démarrage (style Apache qui doit écouter explicitement sur une interface VPN que systemd n'a pas réussi à monter correctement). Je ne te parle même pas des firewalls en cas d'interfaces réseau renommées ! Je n'ai pas vu de problèems de routage associé à systemd parce que lorsqu'il arrive à traiter une interface, elle est traitée jusqu'au bout. Le problème de systemd, c'est dans les détails. After ou Requires fonctionnent moyennement parce certains daemons commencent par se forker eux-mêmes (même deux fois). Il y avait une version d'OpenVPN qui faisait cela et renvoyait un beau 0 à systemd, lequel considérait que les interfaces tap était existantes et continuait. Manque de bol, aléatoirement, elles n'étaient pas encore montées lorsque les services suivants déboulaient pour les utiliser ! Je ne sais plus comment j'ai corrigé le problème, mais j'ai passé du temps dessus ! Je me demande s'il n'y a pas un script quelque part qui va regarder dans les interfaces réseau si les tap0/1/2 sont montées et qui est un prérequis d'apache. Simple comme solution ! Avec SysV ou rcorder, la solution est particulièrement triviale. > Alors, oui, je sais, l'architecture c'est super important. Je m'engueule > assez souvent avec des architectes et des gens de la sécurité pour savoir > quelles sont les contraintes. Et c'est marrant, mais systemd, c'est > jamais, mais alors jamais, dans la liste des sujets. C'est chez moi que > j'ai découvert ça. Quand les architectes me proposent une solution, > plein de trucs peuvent être mentionnés, mais jamais systemd ne rentre en > ligne de compte : ils s'en cognent. Quand on est intoxiqué, on n'arrive même pas à imaginer qu'il existe autre chose. C'est un syndrome assez classique, surtout dans l'informatique où lorsqu'on a un marteau, tous les problèmes ressemblent à des clous. [..] > puces si certaines machines tombaient. > Au boulot, l'un des très gros sujet vient des interfaces entre les > systèmes. Ça, c'est problématique, ça pose plein de soucis de fiabilité > de sécurité, de plein de trucs. > Au boulot, un autre sujet sensible vient à la fois de la sensibilité des > informations pour savoir quelle sécurité appliquer dessus ainsi que la > loi RGPD. Et ça c'est très compliqué car c'est autant décisionnel que > légal que technique. À ton boulot, tu as la chance d'être devant une machine pour faire de la maintenance. Dans le mien, la machine est potentiellement à 1000 km sans possibilité d'intervenir dessus. Dans mon boulot, je n'ai pas forcément un serveur de test dans la même configuration sous la main pour tester une migration. La migration se fait à chaud chez le client sur ses heures de boulot. Ça _doit_ marcher. Et lorsque systemd se met à foutre le bordel parce qu'il a décidé de fonctionner différemment d'une version à l'autre, j'aimerais bien avoir les devs du bouzin sous les pattes pour leur dire ma façon de penser. Dans une grosse boîte, ce genre de problème est limité parce que l'infrastructure est beaucoup plus importante. Tu ne vas pas avoir le même serveur qui fait routeur/passerelle/proxy web/proxy SIP/serveur NFS/Samba/VPN/Apache et j'en passe. Sur les configurations standard, ça passe à peu près. C'est sur les configurations tordues que ça merdoie. > Le problème d'Oracle qui se met à faire payer java, par exemple, c'est > un vrai sujet parce que ça oblige à savoir où se trouvent les jdk sur > tous les serveurs. Oracle qui fait payer Java, ça me mettrait plutôt en joie. > Le sujet de dégager les Windows 2003 qui continuent à > trainer c'est un vrai sujet. Le sujet des Red Hat 2 qui continuent à > trainer c'est un vrai sujet. Le sujet des applications mal codées qui > coûtent une fortune en maintenance, c'est un vrai sujet. > Mais le sujet de systemd, au boulot : tout le monde s'en bat les flanc. Tout le monde s'en bat les flancs jusqu'au jour où vous aurez une belle merde que personne n'avait vu venir parce que tout le monde s'en battait les flancs et que, jusqu'ici, tout fonctionnait bien. J'ai un client qui a fait faillite à cause, entre autres, d'un problème comme ça. > Que ce soit pour des sauvegardes. Que ce soit pour des applications sur > le DRP, pour des applications sur le cloud, pour des applications sur > dans les centres de services. Pour des petites applications ou des gros > ERP. Pas une fois, sur tous les problèmes que j'ai pu entendre, pas une > fois quelqu'un m'a dit que c'était l'ordonnancement qui n'était pas > maîtrisé et qu'on ne pouvait pas choisir l'ordre de démarrage. Et je > vais te dire que des sujets j'en ai vu passer. Ce que tu m'écris est ridicule. Quand tu es devant une machine, tu te contrefiches de savoir si le démarrage s'est passé correctement jusqu'au bout. Si un daemon ne tourne pas, tu le lances à la main. Lorsque tu es devant une machine pour la redémarrer et que systemd décide de partir en attente infinie, tu as le bouton reset. Ça n'a strictement rien à voir avec la capacité de systemd à lancer une application à la demande une fois que tout est démarré. J'ai un souvenir ému d'un tomcat qui refusait de partir sous systemd. Solution des devs de systemd : utiliser un script dans cron pour vérifier qu'il est lancé cinq minutes après le démarrage !... Sérieux ? Maintenant, lorsque ça merde pour une raison indéfinie et que tu es contraint de mettre les mains dans le cambouis, ça coûte nettement plus cher de remettre d'équerre un système utilisant systemd qu'un système utilisant SysV ou rcorder. Pourquoi ? Parce que le temps, c'est de l'argent et que les solutions aux problèmes systemd oscillent entre les problèmes de lutins et de chapelier fou. Sur le papier, c'est simple. Dans les faits, ça peut être extrêmement tordu parce que systemd fait des hypothèses fortes sur le fonctionnement des programmes qu'il lance. JKB |
|
|
Discussions similaires | |
Redhat Entreprise ou maj de Redhat 9
|
|
RedHat ES3 et RedHat classique
|
|
Gel de ma Redhat
|
|
4 cds redhat EL 3.0
|
Fuseau horaire GMT +2. Il est actuellement 13h51. | Privacy Policy
|