Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). ... Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions
Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.
SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 ... AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).
Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Dans mon post j'explique clairement ce que je veux dire :
En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Tu bullshites ( comme d'hab sur certains sujets, donc je vais pas passer du temps à te répondre ). ... Mais peut être que tu veux dire qu'il faut rajouter des autorisations quand on rajoute des fonctions
Non, je parle des cgroups et de selinux.. Par exemple pour les cgroups : si tu veux que deux services partagent le même cgroup, ou si tu veux que ton cgroup de tagging serve aussi à créer des limites, ou si tu veux avoir plusieurs cgroups sur un service ou des dizaines d'autres choses. En fait quand les cgroups ont été créés, certaines personnes ont eu l'idée (idiote je le reconnais aujourd'hui, mais à l'époque c'était difficile à voir) que ça pouvait servir à autre chose qu'à permettre à un système d'init qui serait écrit plusieurs années plus tard. Un des trucs fantatisque (pour un admin) était les hiérarchies, créer un cgroup "database" qui a la priorité partout, et un cgroup "frontend" qui n'a le droit d'utiliser qu'un seul CPU, à peine un peu de bande passante et de mémoire. Bref les trucs fondamentaux vont dans le cgroup "database" et les autres trucs vont dans le cgroup "frontend" - donc même si un crétin avec les droits roots lance une commande bouffeuse de ressources, la base de données aura toujours quoi qu'il arrive 80% des ressources réservées pour elle. C'est cool c'est génial c'est beau.
SAUF QUE - systemd va venir se servir du tagging des cgroups pour faire sa sauce, et la c'est le drame. Par exemple si j'ai l'habitude de faire des triplets apache/mysql/php en fastCGI et de les mettre dans le même cgroup pour limiter (par exemple) la consommation CPU dudit cgroups. Typique je lance 10 triplets AMP dans 10 cgroups AMP0, AMP1 ... AMP9 qui déscendent tous de AMP_MASTER qui limite la consomation CPU à 25% MAX. Je vais pas rentrer dans les détails, mais pour faire un truc pareil avec systemd tu vas morfler. Une fois dans un cgroup un process ne peux pas en sortir, une fois un cgroup activé aucun process ne peut rentrer dedans. Et tu ne peux même plus utiliser le tagging pour suivre le lancement de tes process parce que systemd utilise le sien propre (et qu'un sous système ne peut se trouver à deux endroits d'une même hiérarchie bien sur).
Voilà typiquement un exemple d'utilisation de cgroups que systemd empêche de faire fonctionner. Et typiquement pour t'en sortir il faut repenser tes policies.
Oups, tu peut remplir un bug pour Fedora, car visiblement, la fedora 20 que j'ai a l'air de réussir à le lancer, et visiblement, ç'est un bug que ça marche.
Dans mon post j'explique clairement ce que je veux dire :
Fedora a écrit un wrapper qui a son tour lance HAProxy - sinon c'est la guerre au moment des reloads.