On vous parle depuis longtemps de systemd. On vous dit que c’est très bien. La plupart des distributions l’ont adopté (Fedora, openSUSE, Mageia, Frugalware, Arch, etc.), vont l’adopter (Debian, Ubuntu) ou vous permettent de l’utiliser de manière optionnelle (Gentoo, etc.). Mais, savez‐vous l’utiliser ?
Voici une série d’articles didactiques pour apprendre à utiliser systemd et vous permettre de mieux l’appréhender et de comprendre les avantages qu’il apporte par rapport aux systèmes précédents.
Les informations ci‐dessous sont tirées, traduites et adaptées du blog de Lennart Poettering et sont accessibles dans la langue de Shakespeare aux adresses ci‐dessous :
Sommaire
Partie 1 : vérifier le démarrage
Comme vous le savez, systemd est le mécanisme d’initialisation de nombreuses distributions. Il est également en cours d’adoption par de nombreuses autres distributions (comme Debian et Ubuntu). systemd fournit une variété de nouvelles fonctionnalités, modifie et facilite les processus d’administration du système.
Cet article est le premier d’une série — dans chacun d’eux, j’essaierai d’expliquer une nouvelle fonctionnalité de systemd. Ces fonctionnalités sont souvent simples. Ces articles devraient donc intéresser un large public. Cependant, de temps en temps, nous plongerons plus en détail dans les nouveautés géniales que systemd apporte.
Traditionnellement, lorsque l’on démarre un système Linux, on voit une liste de petits messages défiler à l’écran. Comme nous travaillons à accélérer et paralléliser le processus de démarrage, ces messages défilent de plus en plus vite et sont de moins en moins lisibles — sans compter que les machines deviennent de plus en plus rapides et que les systèmes de démarrage graphique comme Plymouth masquent carrément ces informations.
Malgré tout, les informations de démarrage restent toujours très utiles parce qu’elles vous montrent, pour chaque service, s’il a réussi à démarrer correctement ou non (à l’aide des indicateurs [ OK ] verts et [ FAILED ] rouges). Pour rendre cette information plus accessible, nous avons rajouté une fonctionnalité à systemd qui surveille et enregistre pour chaque service s’il a démarré correctement, s’il s’est terminé avec un code de sortie différent de zéro ou s’il s’est terminé de façon anormale (par erreur de segmentation ou similaire). Et ceci, non seulement au démarrage, mais aussi s’il a un problème par la suite. En tapant simplement systemctl dans votre terminal, vous pouvez interroger l’état de tous les services, tant systemd que SysV/LSB :
[root@lambda] ~# systemctl
UNIT LOAD ACTIVE SUB JOB DESCRIPTION
[…]
netfs.service loaded active exited LSB: Mount and unmount network filesystems.
NetworkManager.service loaded active running Network Manager
ntpd.service loaded maintenance maintenance Network Time Service
polkitd.service loaded active running Policy Manager
prefdm.service loaded active running Display Manager
[…]
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
JOB = Pending job for the unit.
221 units listed. Pass --all to see inactive units, too.
[root@lambda] ~#
J’ai un peu raccourci la sortie ci‐dessus et supprimé quelques lignes sans intérêt pour cet article.
Regardez la colonne ACTIVE. Elle vous montre l’état général d’un service (ou de n’importe quelle sorte d’unité que systemd maintient, qui peut être plus qu’un service — mais nous y jetterons un œil lors d’un futur article).
Il est soit actif (en cours d’exécution), soit inactif (arrêté), soit dans n’importe quel autre état. Si vous regardez attentivement, vous remarquerez un élément dans la liste étiqueté « maintenance » en rouge (NdT : malheureusement, pas de couleur sur LinuxFr.org !). Ce signalement vous informe qu’un service n’a pu s’exécuter ou a rencontré un problème. Dans le cas présent, il s’agit de ntpd. Regardons maintenant ce qu’il s’est passé avec ntpd grâce la commande systemctl status :
[root@lambda] ~# systemctl status ntpd.service
ntpd.service - Network Time Service
Loaded: loaded (/etc/systemd/system/ntpd.service)
Active: maintenance
Main PID: 953 (code=exited, status=255)
CGroup: name=systemd:/systemd-1/ntpd.service
[root@lambda] ~#
La sortie nous montre que le service NTP s’est terminé brutalement (il avait alors l’identifiant de processus 953) et nous donne la condition d’erreur exacte : le processus s’est terminé avec le code de sortie 255.
Dans une prochaine version de systemd, nous avons l’intention de le relier à ABRT, dès que cette demande d’amélioration aura été honorée. Alors, lorsque systemctl status vous affichera les informations concernant un service qui aura planté, il vous redirigera directement sur la vidange de plantage (crash dump) adéquate dans ABRT.
Résumé : systemctl et systemctl status sont des remplaçants modernes et sont plus complets que les traditionnels messages d’état des services SysV au démarrage. systemctl status enregistre non seulement plus de détails, mais montre aussi les erreurs qui ont eu lieu après le démarrage.
Partie 2 : quels services possèdent quels processus ?
Sur la plupart des systèmes GNU/Linux, le nombre de processus en fonctionnement est important. Il est de plus en plus difficile de savoir quel processus fait quoi et d’où il vient. Certains ont même plusieurs processus de travail qui surchargent la sortie de ps avec beaucoup de processus additionnels souvent difficiles à reconnaître. Ça se complique encore avec les démons qui lancent des processus tiers, comme Apache le fait avec les processus CGI ou cron avec les tâches utilisateurs.
Souvent, le seul demi‐remède consiste à regarder l’arbre d’héritage des processus tel qu’il est donné par ps xaf, mais ce n’est généralement pas fiable. Les processus orphelins sont réassignés au processus 1 et, par conséquent, toutes les informations d’héritage sont perdues. En faisant deux forks() successifs, un processus peut perdre sa relation avec celui qui l’a lancé (c’est supposé être une fonctionnalité et cela repose sur le comportement traditionnel de création de démons sous UNIX). Par ailleurs, les processus peuvent à leur convenance changer leur nom grâce à PR_SETNAME ou en modifiant argv[0], rendant ainsi leur reconnaissance plus difficile. En fait, ils peuvent ainsi jouer à cache‐cache avec l’administrateur assez aisément.
Avec systemd, nous plaçons chaque processus engendré dans un groupe de contrôle (cgroup) nommé d’après le service. Les groupes de contrôle, du point de vue le plus élémentaire, sont simplement des groupes de processus qui peuvent être classés hiérarchiquement et étiquetés individuellement. Quand des processus engendrent d’autres processus, ces enfants sont automatiquement membres du cgroup de leur parent. Quitter un cgroup n’est pas possible pour un processus sans privilège. C’est pourquoi les cgroups peuvent être utilisés pour étiqueter tous les processus d’un service efficacement et indépendamment du nombre de forks() ou de renommages. En allant plus loin, les cgroups peuvent être utilisés pour tuer proprement un service et tous les processus qu’il a créés, sans exception.
Dans le billet d’aujourd’hui, je veux vous présenter deux commandes permettant de faire le lien entre les services créés par systemd et les processus. La première est la commande bien connue ps, qui a été mise à jour pour afficher les informations cgroup à côté des autres informations. Ça ressemble à ceci :
$ ps xawf -eo pid,user,cgroup,args
PID USER CGROUP COMMAND
2 root - [kthreadd]
3 root - \_ [ksoftirqd/0]
4281 root - \_ [flush-8:0]
1 root name=systemd:/systemd-1 /sbin/init
455 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d
8188 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d
8191 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d
1131 root name=systemd:/systemd-1/auditd.service auditd
1133 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd
1171 root name=systemd:/systemd-1/NetworkManager.service /usr/sbin/NetworkManager --no-daemon
4028 root name=systemd:/systemd-1/NetworkManager.service \_ /sbin/dhclient -d -4 -sf /usr/libex[...]
1193 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -c 4
1195 root name=systemd:/systemd-1/cups.service cupsd -C /etc/cups/cupsd.conf
1210 root name=systemd:/systemd-1/irqbalance.service irqbalance
1216 root name=systemd:/systemd-1/dbus.service /usr/sbin/modem-manager
1219 root name=systemd:/systemd-1/dbus.service /usr/libexec/polkit-1/polkitd
1332 root name=systemd:/systemd-1/getty@.service/tty2 /sbin/mingetty tty2
1339 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3
1344 root name=systemd:/systemd-1/crond.service crond
1362 root name=systemd:/systemd-1/sshd.service /usr/sbin/sshd
1376 root name=systemd:/systemd-1/prefdm.service /usr/sbin/gdm-binary -nodaemon
1391 root name=systemd:/systemd-1/prefdm.service \_ /usr/libexec/gdm-simple-slave --displa[...]
1394 root name=systemd:/systemd-1/prefdm.service \_ /usr/bin/Xorg :0 -nr -verb[...]
1495 root name=systemd:/user/lennart/1 \_ pam: gdm-password
1521 lennart name=systemd:/user/lennart/1 \_ gnome-session
1621 lennart name=systemd:/user/lennart/1 \_ metacity
1635 lennart name=systemd:/user/lennart/1 \_ gnome-panel
1638 lennart name=systemd:/user/lennart/1 \_ nautilus
1453 root name=systemd:/systemd-1/dbus.service /usr/libexec/upowerd
1473 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
Notez que la sortie est un peu raccourcie. J’ai supprimé la plupart des tâches du noyau ici, car elles n’ont pas d’intérêt pour cet article.
Dans la troisième colonne, vous pouvez voir le cgroup systemd assigné à chaque processus. Vous verrez que les processus udev sont rassemblés dans le cgroup name=systemd:/systemd-1/sysinit.service. C’est le cgroup utilisé pour tous les processus démarrés par le service sysinit.service, qui s’occupe du début du démarrage.
Je recommande personnellement de créer pour la commande ps ci‐dessus l’alias suivant :
alias psc='ps xawf -eo pid,user,cgroup,args'
Avec ce service, les informations sur les processus ne sont plus qu’à quatre touches de distance !
L’outil systemd-cgls fourni avec systemd est un autre moyen de présenter ces mêmes informations. Il affiche la hiérarchie des cgroups sous forme d’arbre. Sa sortie ressemble à ceci :
$ systemd-cgls
+ 2 [kthreadd]
[...]
+ 4281 [flush-8:0]
+ user
| \ lennart
| \ 1
| + 1495 pam: gdm-password
| + 1521 gnome-session
| + 1621 metacity
| + 1635 gnome-panel
| + 1638 nautilus
| \ 29519 systemd-cgls
\ systemd-1
+ 1 /sbin/init
+ rtkit-daemon.service
| \ 1473 /usr/libexec/rtkit-daemon
+ prefdm.service
| + 1376 /usr/sbin/gdm-binary -nodaemon
| + 1391 /usr/libexec/gdm-simple-slave --disp[...]
| \ 1394 /usr/bin/Xorg :0 -nr -verbose -auth [...]
+ getty@.service
| + tty3
| | \ 1339 /sbin/mingetty tty3
| \ tty2
| \ 1332 /sbin/mingetty tty2
+ crond.service
| \ 1344 crond
+ sshd.service
| \ 1362 /usr/sbin/sshd
+ irqbalance.service
| \ 1210 irqbalance
+ NetworkManager.service
| + 1171 /usr/sbin/NetworkManager --no-daemon
| \ 4028 /sbin/dhclient -d -4 -sf /usr/libexe[...]
+ rsyslog.service
| \ 1193 /sbin/rsyslogd -c 4
+ cups.service
| \ 1195 cupsd -C /etc/cups/cupsd.conf
+ auditd.service
| + 1131 auditd
| \ 1133 /sbin/audispd
| \ 1135 /usr/sbin/sedispatch
\ dbus.service
+ 1216 /usr/sbin/modem-manager
\ 1219 /usr/libexec/polkit-1/polkitd
Cette sortie est également raccourcie.
Comme vous pouvez le constater, cette commande montre les processus par leur cgroup et ainsi leur service, car systemd nomme les cgroups d’après les services. Par exemple, vous pouvez facilement voir que le service d’audit auditd.service lance trois processus indépendants, auditd, audisp et sedispatch.
Si vous y regardez de plus près, vous remarquerez que plusieurs processus ont été assignés au cgroups /user/1. Pour le moment, restons en là : systemd non seulement maintient des services dans les cgroups, mais aussi les processus de session utilisateur. Dans le prochain épisode, nous parlerons plus en détail de ce sujet.
C’est tout pour aujourd’hui ! La suite au prochain épisode !
Aller plus loin
- systemd for Administrators, Part 1 (3033 clics)
- systemd for Administrators, Part 2 (1792 clics)
# Formation
Posté par barmic . Évalué à 10. Dernière modification le 02 août 2014 à 09:59.
Voila de quoi permettre aux bons pères de familles travaillant pour des employeurs tyranniques les obligeants à utiliser des choses bizarres comme la dernière version de RHEL ou CentOS de se former sur le temps de troll plutôt que sur leur temps libre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par deuzene (site web personnel) . Évalué à 8.
D'abords merci pour cette dépêche fort instructive. J'attends la suite avec impatience.
Je ne suis pas un informaticien, la seule machine que j'administre étant la mienne. Mais le futur de ma distribution m'oblige à me pencher sur le sujet. Et cette formation, via dépêches, trolls et discussions, s'annoncer forte utile. Et tout ça sur un temps de détente.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: Formation
Posté par zurvan . Évalué à -10.
c'est moche comme tout.
On dirait des trucs écrits par micro$oft, je ne sais pas pourquoi, une impression, c'est dans la lignée des cochennerie de base de registre style dconf, avec des retours de commande façon « corporate » ("CGroup: name=systemd:/systemd-1/ntpd.service"), bref, une syntaxe qui fait mal aux yeux, et une technologie qui sera vite oubliée dans le monde Unix d'ici 4-5 ans une fois que ça se sera vautré (façon consolekit), mais on peut faire confiance à la clique de Red Hat, ça sera remplacé par un bidule encore plus usine à gaz et encore plus merdique.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Formation
Posté par Misc (site web personnel) . Évalué à 10.
En fait, l'inspiration est le format utilisé pour les fichiers .desktop ( http://standards.freedesktop.org/desktop-entry-spec/latest/ ), lui même inspiré du format de fichier .ini qu'on retrouve à beaucoup à l'époque de windows 3.11, et qui, d'aprés wikipedia, trouve ses origines dans windows 1.0.
C'est un format qui est nativement compris par pas mal de language ( python, perl, etc ), avec des implémentations matures, et facile à comprendre par la plupart des gens ( au contraire de json ou yaml qui requiert de comprendre la syntaxe un minimum ). Ceci dit, si ça ne te plait pas, tu peux toujours utiliser un generateur qui va convertir les unités d'un format de ton choix vers ce que systemd comprends.
Je suis sur que tes critiques seraient prises plus au sérieux sans l'usage de terme comme merdique, cochonneries et usine à gaz, et surtout avec un truc plus précis que "une syntaxe qui fait mal aux yeux", car je doute franchement que ça soit une description litéral de ce qui t'arrive. Je suis sur qu'on peut te mettre dans un ORM et vérifier qu'aucun centre de la douleur n'est activé par la syntaxe, et qu'il s'agit juste d'une métaphore, ce qui n'aide pas vraiment le propos de part son imprecision.
[^] # Re: Formation
Posté par freem . Évalué à 4.
Accessoirement, c'est surtout un format qui est réellement lisible par l'homme, tous les hommes, y compris ceux n'ayant pour eux qu'une simple curiosité (mais pas de connaissance réelle de l'informatique).
C'est également un format efficace, tant au niveau de la mémoire (et je parle à la fois de la RAM et du stockage ici) que des performances CPU: il suffit d'un simple scanf pour parser une ligne d'un fichier INI, contrairement aux langages véritable horribles que l'on voit fleurir: XML, JSon, pour ne citer qu'eux.
Enfin, je trolle sur ces techno, mais en fait je ne le pense pas, pas complètement du moins. Je pense juste qu'ils sont mal utilisés 80% du temps.
Quant aux logiciels qu'il faut configurer via un langage de script, comme l'ancien init (auquel je reste, mais pour des raisons différentes: j'aime les choses qui ont un couplage faible avec le reste du système, ce que systemd n'est pas. Entres autres.) ils sont probablement l'une des raisons pour lesquelles un certain nombre de personnes pensent que Linux n'est pas prêt pour être utilisé par Monsieur tout le monde sur un PC.
Ben oui, quand il faut apprendre un langage à la syntaxe à la con (avouez: la gestion des chaînes de caractères est loin d'être triviale en shell, sans parler des nombres. Et ce ne sont que des exemples, qui n'aident pas la lisibilité selon moi.) afin d'être capable d'analyser le code existant, dispatché dans de nombreux fichiers eux-mêmes disséminés dans l'arborescence, gérant toutes les situations de tous les systèmes possibles, ce n'est pas une aide, mais une gêne.
Même si je n'apprécie pas systemd, il faut lui reconnaître ça: c'est pour un béotien un vrai bonheur de lire les fichiers de configuration de systemd, comparé aux scripts shell de sysV.
[^] # Re: Formation
Posté par barmic . Évalué à 4.
C'est quand même super bien des fois. Personnellement j'essaie de pousser les fichiers de configuration les plus simples (ça commence avec les fichiers properties), puis on monte en fonction des besoins et en essayant d'éviter d'avoir 612 formats. Mais il arrive qu'un vrai LSM soit génial, c'est par exemple le cas pour vim, gradle et awesome. Tous les logiciels n'ont pas pour objectif d'être Michu-compliant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à 2.
C'est vrai, mais je pense que complexifier la personnalisation (au niveau administration principalement, puis logiciel) d'un système n'est pas une bonne chose. Systemd est sur ce point intéressant pour moi, mais je trouve regrettable d'un autre côté qu'il complexifie de façon injustifiée --à mes yeux-- le plus bas niveau (dépendances des logiciels de plus en plus dures, une archi "modulaire" au couplage douteux, ce genre de choses. Mais je dis peut-être des conneries, je n'ai pas la prétention de maîtriser le sujet.).
M'enfin, on va pas recommencer un troll sur systemd. De toute façon, même si je n'ai manifestement pas l'usage de cet outil, je considère que c'est une bonne chose qu'il soit arrivé: même si ça génère un bruit monstre, un coup de pied dans la fourmilière Linux à plus de chance d'améliorer les choses que le contraire: dans le pire des cas, des distros seront forkées, et que le meilleur gagne.
[^] # Re: Formation
Posté par barmic . Évalué à 3.
Un bon DSL (qui garde les choses simples, simples) et un bon bootstrap (qui découpe la configuration en plusieurs fichiers voir plusieurs dossiers) rendent ça très simple. C'est là qu'on voit les DSL bien foutu. Le
.vimrcmoyen est très proche du fichier properties, mais est un vrai langage de programmation complet qui quand tu en a besoin pourra t'être très utile, le bootstrap de vim permet d'avoir une configuration system-wide et une configuration par utilisateur. Mais il faut en avoir le besoin, pour moi, systemd démontre que ce n'est pas nécessaire pour l'init.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à 1.
Yep, je suis bien d'accord.
[^] # Re: Formation
Posté par ariasuni . Évalué à 2.
Bon j’ai trouvé ce que DSL voulait dire, par contre je ne vois pas ce que LSM veut dire dans ce contexte (dans ton commentaire précédent)…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par barmic . Évalué à 3.
C'est une erreur
s/LSM/DSL/Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à -1.
Zut, je pensais que c'était un équivalent de LSD :p (bon ok je sors)
[^] # Re: Formation
Posté par tyoup . Évalué à 0.
Moi c'est l'inverse je ne vois pas le lien avec Damn Small Linux…
[^] # Re: Formation
Posté par ariasuni . Évalué à 5.
J’ai du mal à voir l’intérêt d’un faible couplage entre le système d’init et le noyau quand on voit les avantages notamment en terme de sécurité et de fonctionnalité.
Et puis c’est pas comme si systemd était compatible avec rien: il peut fonctionner sur toutes les distributions GNU/Linux!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par freem . Évalué à 0.
Pour les fonctionnalités, je veux bien. Pour la sécurité, je veux bien… que tu développes un peu plus.
Sinon, le couplage faible avec le noyau, ok, c'est pas utile. Mais j'ai parlé du système, moi, pas juste du noyau, et même si ce n'est pas la faute de systemd si GTK et KDE commencent manifestement à intégrer des dépendances en dur à celui-ci, c'est malgré tout regrettable.
Sinon, le fait de faire des choses portables nécessite en général un couplage plus faible. Et la portabilité permets, selon moi mais c'est juste une opinion, d'améliorer la qualité des logiciels, autant en perfs qu'en sécurité (plus de compilos utilisables, plus de warnings détectés, par exemple). Mais bon, déjà, ça marche, c'est excellent en soit et il m'arrive d'utiliser des softs non portables, quand ils m'apportent une réelle plus-value. Donc peut-être que je me laisserai convaincre par systemd un de ces 4, après tout, j'ai quand même quelques attirances pour certains de ses aspects.
Euh… hum… ouai, en fait, tu dis que systemd peut marcher avec tous les kernel linux. Humhum.
[^] # Re: Formation
Posté par barmic . Évalué à 7.
systemd rend facilement accessible des fonctions de sécurité (cgroup, namespace,…). Très rare sont les scripts d'init qui s'en servaient et maintenant c'est suffisamment simple (et reproductible entre distribution) pour être intégré de base.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par ariasuni . Évalué à 4.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par freem . Évalué à -1.
Chez moi, gtk3 à des dépendances à systemd si on suit la cascade de dépendances.
[^] # Re: Formation
Posté par ariasuni . Évalué à 2.
Pourtant j’ai bien précisé «distributions GNU/Linux» et pas «noyaux Linux».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par spider-mario . Évalué à 3.
Vu que KDE cherche à faire fonctionner ses logiciels sur Windows et OS X, ça m’étonnerait que systemd devienne une dépendance absolue.
[^] # Re: Formation
Posté par barmic . Évalué à 6.
D'autant que la compatibilité de sysv avec autre choses que les distributions linux est toute théorique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freeze . Évalué à 2.
voire même … entre distributions GNU/Linux.
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 2.
(Pardon pour les accents!)
Independemment de tout systeme d'init un admin doit connaitre le shell, donc en fait, un systeme d'init base sur le shell est base sur un systeme bien compris par un admin.
Chez moi, ce n'est pas comme ca (FreeBSD), il y a essentiellement
/etc/rc, la bibliotheque/etc/rc.subrqui encapsule la logique de demarrage de services, puis chaque script de service, ce qui signifie que si tu veux comprendre un demarrage de service, tu dois lire rc.subr (qui a une page de man, en plus!) et ton fichier de demarrage de service: c'est une situation bien moins atroce que ce que tu depeins.Les accents sont la:'
'^'[^] # Re: Formation
Posté par freem . Évalué à 1.
Mais tous les utilisateurs de systèmes non windows ne sont pas nécessairement, ni ne veulent être, de bons admin. Admin, c'est un métier, qui à l'air super intéressant de mon point de vue et aller fouiller dans les scripts et autres man ne me fait pas peur quoiqu'on puisse penser de mes propos, mais en premier contact ce n'est pas vraiment aisé.
Peut-être. Toujours est-il que j'ai essayé de le faire à ma façon sous Debian, c'est à dire en fouillant dans le man et en lisant le code source. Franchement, j'ai été largué, mais c'est vrai aussi que je suis bien plus habitué à des langages type Java, C++ et compagnie.
Après, peut-être aussi que sur d'autres systèmes les scripts sont plus clairs. Je songe justement à aller tester un des BSD depuis quelques temps, histoire de voir de quelle couleur est l'herbe à côté.
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 3.
D'une on ne parle pas de tous les utilisateurs mais de ceux qui ont quelque chose `a faire de ce qui se passe au demarrage de l'ordinateur. Peut-etre qu'ils veulent lancer un service au demarrage qu'ils ont prepares. Et n'importe qui sachant programmer un service qui doit se lancer au demarrage a a priori les competences pour trouver le moyen de l'integrer a sa sequence de boot en moins d'une heure et demie, quelque soit le systeme de boot.
De deux, quand on utilise un systeme Unix, programmer le shell est la competence technique la plus importante, et donc baser un systeme technique sur le shell n'est pas une barriere d'entree au contraire!
[^] # Re: Formation
Posté par ariasuni . Évalué à 5.
Certes, mais il faut admettre que le format déclaratif de systemd est quand même plus simple. Sans connaitre aucun langage de programmation, je peux faire une unité, la vérifier et la corriger.
Faut tout de suite que j’éteigne ma machine personnelle sous Arch Linux pour y installer Windows, et que j’arrête mon serveur auto-hébergé alors. Tant pis pour moi et les utilisateurs de GNU/Linux un peu curieux qui se casseront les dents sur le shell.
Ce n’est pas parce que (supposition) je connais le brainfuck qu’utiliser le brainfuck n’est pas une barrière d’entrée… Je comprends pas cette volonté de défendre le shell à tout prix quand dans la majorité des cas un autre langage serait tout aussi adapté mais plus compréhensible.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par ariasuni . Évalué à 3.
Avec une mentalité comme ça on continuera à se cogner le shell pendant des années… Tous les trucs que je faisais (ou j’essayais de faire) auparavant en shell je les fait en Python. Même si en général c’est un peu plus verbeux, c’est tellement plus intuitif et lisible (même pour quelqu’un qui ne connait pas le langage).
D’autre part, je peux avoir envie de me faire une unité (service, minuteur) ou surcharger une unité existante sans être admin sys (et pour servir un des buts de systemd, à savoir maintenir l’unité systemd en amont, mieux vaut que ça soit simple pour que ça soit fait).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 0.
Donc tu n'aimes pas le shell et tu preferes Python, mais en quoi ca nous concerne?
Sinon le shell est clair et lisible si on veut:
C'est le petit script de cet apres-midi pour cloner les repositories git de
$basedir/john/projet.gitenjohn-projet.git.En gros tu me dis que tu peux avoir envie d'etre une personne avec un profil technique quand il faut avoir envie de faire une unite et un profil plutot pas technique quand on en vient a integrer cette unite au systeme de boot? Pas tres convaincant!
La verite, c'est qu'il s'agisse de systemd ou de l'init old-school, une personne avec un profil technique qui ne connait pas le systeme en question et qui veut integrer son schmouzin au boot va avoir besoin de 30min—1h30, et que si systemd a des atouts indiscutables, la simplicite est un argument completement pipeau.
[^] # Re: Formation
Posté par tyoup . Évalué à 5.
comme tu dis : si on veut :-D
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à -1.
Oui, oui! :-)
Ce n'est pas du shell, c'est sed, si tu as une meilleure solution avec un meilleur outil externe, tu peux l'inserer ici!
Le concours est ouvert!
[^] # Re: Formation
Posté par tyoup . Évalué à 1.
Non, non ! Moi j'attends la solution shell pur :-D
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à -1.
Ce serait effectivement dommage de realiser que le langage ou le traitement fait avec
seds'exprime clairement n'existe pas.[^] # Re: Formation
Posté par barmic . Évalué à 9. Dernière modification le 06 août 2014 à 23:46.
Il y a quand même pleins de façon plus lisibles de faire ça :
Ma version sed, demande à connaître les expressions régulières ce qui est largement plus courant que le langage sed et qui est plus visuel aussi.
La version awk (la plus lisible des 4 AMHA) demande à savoir comment fonctionne awk (
-Fpour découper les lignes et le bloc s'execute pour chaque ligne).La version zsh consiste à découper la ligne sur les
/et à concaténer les deux derniers éléments avec un - (c'est l'opérateur j pour join).Il y a, je pense, 4 façons générales de le faire :
/(les versions awk et zsh)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 3.
Effectivement la version
awkest la mieux, et c'est la seule qui est vraiment tres claire et tres concise.[^] # Re: Formation
Posté par Zenitram (site web personnel) . Évalué à 1.
On n'a pas la même façon de voir clair…
Je ne sais pas pour les autres, mais la version Java m'est carrement plus claire : je connais l'anglais, ça aide. Note : je ne connais pas Java plus que awk ou sed, et j'ai du mal avec les expressions régulières aussi.
A force, on va arriver à Java, ou… à Python comme la personne à qui tu reprochais de ne pas connaitre le shell ;-).
J'avoue vraiment avoir du mal à comprendre qu'une personne puisse trouver la version awk plus claire que la version Java : un bon rapport entre rapidité d'écriture et apprendre comment ça marche, peut-être, mais pour une personne arrivant, la version Java est bien plus lisible.
Note : dans tous les cas, ça manque de commentaires ;-).
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 2.
C'est clair quand tout ce qui a du sens est mis en avant et que l'accessoire est laisse derriere, que la structure est simple a changer, etc.
Penser qu'un programme est clair lorsqu'il est a peu pres comprehensible par quelqu'un ne comprenant pas le langage n'a rien a voir avec la clarte mais avec d'autres qualites du langage --- et surtout cela fournit une definition dependant de l'observateur, le genre de definitions pas super utile.
La version awk dit: decoupe chaque ligne d'input selon les
/, et ecrit la ligne d'input suivie de|suivie de l'avant-dernier field suivi de/suivi du dernier field.La version java est plus embrouillee (getName, c'est du babillage administratif, i.e. du bruit).
[^] # Re: Formation
Posté par Zenitram (site web personnel) . Évalué à -3.
Autant de bruit que la langue qu'on utilise pour parler ensemble : cette langue est facilement compressible, pourquoi donc ne pas réduire le bruit?
Bizarrement, sans doute parce que c'est plus facile à comprendre.
Que ceux qui aiment sed et compagnie discuttent (orale/écrit) avec cette meme langue entre eux (à coup de /, | et j'en passe plutôt que "découpe" et "écrit"), pour montrer qu'ils pensent réellement ce qu'ils disent. Moi, je dis que c'est du bluff.
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 2.
Tu penses "etre clair = je peux le comprendre sans connaitre" et si ca ne t'interesse pas d'essayer de discuter ce point et que tu preferes le tenir pour acquis et continuer balancer tes jugements a l'emporte-piece, je te propose qu'on arrete de faire chier tout le monde ici et qu'on se connecte sur le canal de discussion approprie:
[^] # Re: Formation
Posté par freem . Évalué à 3.
Même si je suis plutôt d'accord avec les points que tu soulèves, je dirais qu'il faut distinguer clair et accessible en programmation.
Le langage Java est conçu pour être très accessible, mais un code long sera plus embrouillé qu'un équivalent dans d'autres langages, notamment à cause de la verbosité.
Dans le cas du code awk, il est effectivement plus clair, mais vachement moins accessible. En même temps, awk, sed, shell sont des langages qui me semblent plutôt conçus pour des programmes courts, contrairement à des langages comme Java.
Et cette opinion est la raison même qui fait que je trouve regrettable que les scripts d'init soient faits en shell (passé les 60 lignes de codes, je n'appelle plus ça "court") et non dans un langage plus adapté, éventuellement déclaratif.
[^] # Re: Formation
Posté par anaseto . Évalué à 2.
Perso, je pense que comparer d'un point de vu purement développeur des langages généralistes pour développeur avec des langages spécialisés n'a aucun sens. Java est peut-être plus accessible à un développeur qui connaît déjà les notions d'objet, de classe, d'itérateur, de conversions de types, compilation byte code etc. Awk de son côté ne vise pas spécialement le développeur. D'où la surprise pour le développeur, l'impression que ce langage est rudimentaire (à juste titre), et que toutes ses connaissances développeur ne lui servent à rien pour le démêler. Mais d'un point de vue de quelqu'un qui est juste un utilisateur d'un unix-like, et qui tape juste de temps en temps quelques commandes dans le terminal, awk est juste un petit langage (imparfait !) qui s'apprend en une heure ou deux sans aucun prérequis théorique et lui sert à résoudre des petits problèmes de simple utilisateur.
[^] # Re: Formation
Posté par barmic . Évalué à 4.
Je ne suis pas d'accord avec ton analyse. awk est un langage généraliste, simple, mais qui suis une exécution atypique (il n'y a guerre que perl qui peut se targuer de faire la même chose). C'est ça qui est déroutant pour le développeur. Ensuite c'est un langage qui est conçu pour être "parlé couramment". La concision et la simplicité (dans le sens où il ne doit pas être "battery included") sont primordiale pour ça et c'est plus important que la lisibilité (je parle de priorité pas que la lisibilité est inutile).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par anaseto . Évalué à 3.
Awk est quand même surtout, je pense, un langage pensé pour faire du traitement de texte, préférablement organisé en blocs et champs (avec séparateurs divers), pas pour faire du développement, donc je ne le qualifierais pas de généraliste. Et oui, son exécution est atypique, mais elle n'est pas absurde vu l'objectif du langage. Et si c'est très perturbant pour un développeur, cette exécution se comprend malgré tout avec quelques exemples, et ne demande aucun bagage théorique pour être comprise (contrairement à l'organisation en classes, modules, etc.). Je ne dis pas que awk est lisible, juste plus accessible à un non développeur qu'un langage orienté développement, et ce pour les mêmes raisons qu'un unit systemd est plus accessible qu'un script shell à un utilisateur qui ne connaît même pas le shell. Un unit demande de comprendre uniquement du
clé=valeur(pour ce qui est du langage en soi). Le shell et awk demandent un peu plus : comprendre ce qu'est une chaîne de caractères et un ordre d'exécution. Un langage généraliste (j'entends pour faire du développement de tout type) demande de comprendre beaucoup plus de concepts théoriques.[^] # Re: Formation
Posté par barmic . Évalué à 3.
Jamais dis le contraire, je dis juste qu'à ma connaissance il n'existe que 2 langages qui le font.
Ce n'est pas un fichier properties, mais ini. Il y a une notion de section. Ajouter
clef=valeurà la fin n'a pas forcément le même sens qu'au milieu (contrairement à un fichier properties).Non, awk permet d'écrire des fonctions, divers boucles, des variables, des tableaux, des dictionnaires, de lancer des programmes, de manipuler directement (pas limité à stdin, stdout et stderr) des fichiers, etc il est même possible d'étendre le langage via des modules. Il est effectivement fait pour manipuler des chaines, mais je ne vois pas ce qui lui manque pour être généraliste.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par anaseto . Évalué à 2.
Les tableaux d'awk sont juste des dictionnaires indexés par des chaînes qui représentent des nombres.
Ce n'est vrai que pour gawk je crois.
Mais je suis d'accord qu'on peut faire un peu de tout avec si on insiste. Et puis selon wikipédia l'assembleur et tcl seraient considérés des langages généralistes, donc pourquoi pas awk aussi.
[^] # Re: Formation
Posté par freem . Évalué à 1.
C'est un fait, que l'ASM est généraliste, surtout quand on lis la définition de généraliste:
Traduction grossière: "Un langage généraliste est un langage informatique qui peut être utilisé pour un large éventail de domaines d'application, et manque de fonctionnalités spécialisées pour un domaine précis."
L'ASM entre effectivement dans cette catégorie, il me semble.
Si on prend la liste des DSL de wikipedia, on a, par exemple, HTML. Là, je ne pense pas qu'il soit nécessaire de démontrer qu'il ne s'agit pas d'un langage généraliste?
Du côté d'AWK, selon la liste des fonctionnalités de wikipedia, on à un langage capable de manipuler des fichiers textes. Bien, mais c'est quelque chose de quand même franchement généraliste, je trouve. Je ne dis pas que c'est pourri pour autant, certains langages généralistes sont meilleurs que d'autres dans des applications données, par exemple si on veut de la performance maximale, on s'orientera en général plutôt vers le C ou le C++, alors que si on veut un truc le plus robuste possible, ADA semble être le choix le plus pertinent.
[^] # Re: Formation
Posté par anaseto . Évalué à 3.
En pratique, l'assembleur n'est surtout utilisé, directement, que dans les compilateurs ou pour optimiser certains codes très particuliers. Du coup, de ce point de vue je n'avais pas l'impression qu'il soit généraliste en pratique avec un champ d'application si restreint : servir de langage intermédiaire ou pour contrôler finement des détails de bas niveau. Après, bien sûr, si on considère que toute application qui passe par l'assembleur pour la compilation en code natif est une application de l'assembleur… ;)
Et dans awk la moitié des fonctionnalités tournent autour de la manipulation de fichiers textes structurés en blocs et champs : ça rentre quand même pas très bien dans « manque de fonctionnalités spécialisées pour un domaine précis ».
[^] # Re: Formation
Posté par freem . Évalué à 1.
Si on considère les possibilités, et non les usages effectifs, de l'assembleur, ce qui semble être le cas de la définition de wikipedia, alors leur catégorisation tiens la route, c'est surtout ça que je voulais dire.
Après… je n'ai pas assez de théorie des langages pour savoir si bidule ou machin est généraliste. D'ailleurs, franchement, je m'en cogne. Dans un langage, je veux surtout connaître son point fort et être capable de le lire/écrire aisément, ce qui n'est jamais le cas sans un minimum d'apprentissage, et ça ne tiens jamais sur 2 heures :)
[^] # Re: Formation
Posté par freem . Évalué à 2.
Hum… je suis toujours hyper sceptique quand on m'annonce que tel ou tel langage s'apprend en 2H… en 2H, tu apprendras peut-être les notions de base (pas les bases, hein, juste les notions de base) mais tu ne connaît pas un langage en 2H.
Pour info, quand j'étais à l'école, les profs passaient plus de 4 heure pour les structures de contrôle de base: if/then/else, do/while, while et for. Ce n'est pourtant pas bien compliqué, mais ils avaient jugé qu'il fallait plus de temps que ça.
Et si je lis bien, awk semble en être doté.
Il est aussi doté de choses comme les tableaux associatifs, chose absente dans le premier langage que j'ai appris, entres autres.
Bref, tu dis qu'il ne faut que 2H parce que toi, tu le connais déjà. Perso, je mettrai sûrement assez peu de temps à l'apprendre, mais je suis biaisé: je sais déjà programmer dans plusieurs autres langages. Ceci dit, je doute que je ne mettrai que 2H pour être capable de comprendre n'importe quel programme awk.
[^] # Re: Formation
Posté par anaseto . Évalué à 2.
Je suis d'accord que tout apprendre en deux heures n'est pas possible (du moins sans une expérience dans un autre langage de programmation). Mais en deux heures tu peux déjà écrire (à défaut de comprendre exactement) la plupart des petits cas d'utilisation qui peuvent intéresser un simple utilisateur, et pour lesquels tu n'as typiquement pas besoin de boucles while ni fonctions. En Java au bout de deux heures le simple utilisateur serait incapable de faire grand chose d'utile encore, car obligé de comprendre une plus grande part du langage avant de faire quelque chose.
[^] # Re: Formation
Posté par freem . Évalué à 1.
Hum… je ne suis pas d'accord, en Java en 2H, tu peux apprendre à faire des trucs de base je pense. Bon, je suis biaisé, mais je pense qu'apprendre via un tuto qui explique un pendu en mode texte ou le "plus petit/plus grand" (toujours en mode texte, parce que c'est AMA clairement les trucs les plus simples à coder) doit être faisable pour un non dev (mais pour quelqu'un que ça intéresse et n'est pas 100% ignare en info, hein, faut pas pousser non plus).
Après, pour les dev de métier, c'est différent, ça dépend je pense surtout des langages racines qu'ils connaissent déjà. Quelqu'un qui connaît C ou C++ peut apprendre des trucs poussés en Java rapidement, mais ce ne sera peut-être pas le cas de quelqu'un qui ne connaît que lisp ou pascal par exemple?
[^] # Re: Formation
Posté par barmic . Évalué à 5.
Je comprendrais cette remarque pour les toString(), mais pour les getName(), je ne vois pas. Le getName(), permet de récupérer le nom du fichier pointé plutôt que le chemin complet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par barmic . Évalué à 5.
Personnellement je parlais du plus lisible des 4 premiers.
Je ne connais pas d'autres langages qui utilise une API comme nio/nio2 pour la gestion de fichier. Je ne dis pas que ça n'existe pas, mais je ne les connait pas (il y a boost je crois). python utilise des chaines de caractères dont tu as quelque chose que awk ou zsh.
Note que java est un très mauvais candidat pour pleins de raison (il est compilé, il est lent à démarrer). Perso pour faire ce boulot, c'est zmv que le privilégierais, il est littéralement fait pour.
Personnellement, j'essaie d'en mettre de moins en moins, par exemple avec la version java je ne vois pas l'intérêt de mettre un commentaire pour décrire la transformation (il suffit de lire), j'expliquerais juste quoi on a besoin de se format final.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à 1.
C'est quoi ZMV?
Je n'ai pas réussi à trouver des infos qui semblent pertinentes avec le sujet?
[^] # Re: Formation
Posté par barmic . Évalué à 4.
C'est un module de zsh. Tu peux trouver des exemples là et là et la doc dans man zshcontrib.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par Moonz . Évalué à 3.
Le gros souci de la version Java, c’est qu’il faut en faire un programme, donc :
- Un .java, avec tout le boilerplate autour (class/public static void main/les import)
- En faire un .jar
- À l’utilisation java -jar …
Bref pour un one-liner dans le genre Java c’est clairement overkill indépendamment de la question de la lisibilité du code.
[^] # Re: Formation
Posté par barmic . Évalué à 4.
J'ai mis la version java uniquement parce que c'est une approche totalement différente des autres. Pour s'en servir, il faudrait utiliser l'API à travers groovy, scala ou clojure (je pense que c'est faisable).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par barmic . Évalué à 6.
J'aime beaucoup le shell, mais bon… un jour on se met a en utiliser un qui rend vraiment les choses simples (et donc permet de rendre les choses très complexes accessibles) :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par barmic . Évalué à 6.
Je ne sais pas et je me fou de savoir si systemd est plus simple, mais le fait que l'utilisateur soit un sysadmin ne rend pas la simplicité inutile. Ça peut lui permettre d'être plus rapide ou plus efficace en évitant les erreurs et/ou en simplifiant ces procédures (que ce soit des doc ou des recette ansible/chef/puppet/etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 3.
Tu as bien-sur raison, ce que je mettais en doute est le fait que
systemdsoit plus simple que le systeme d'init, en fournissant une experience de pensee (bien limitee).[^] # Re: Formation
Posté par Zenitram (site web personnel) . Évalué à 2.
lol.
Ton exemple est explicite, disant exactement le contraire de ta phrase.
Peut-être, mais pour le moment je vois plutôt de la magie noire, vu que c'est illisible (surtout, ne pas mettre de commentaires sur ce que fait le sed…)
Merci pour la démonstration.
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 3. Dernière modification le 06 août 2014 à 11:42.
Le programme est construit en utilisant le pattern
query/joblist/processqui est a peu pres la seule un peu exotique qu'il faut comprendre quand on fait du shell. Je vais donc detailler un peu.Le shell est fort pour lancer des processus et aigiuiller les donnees entre differents processus. C'est donc sous la forme de donnees transitant entre des processus --- ou meme de fichiers --- qu'il faut representer toutes les donnees complexes.
Le point clef est le point 2, que beaucoup de programmeurs traitent maladroitement en essayant de representer la joblist dans des variables du shell --- peche mortel!
En plus c'est tres facile a developper et deboguer car on peut facilement isoler un element du pipe pour l'ausculter, faire du mocking (avec
cat)…C'est tres facile a faire evoluer, par exemple s'il faut adapter la methode de backup au sujet, on peut ajouter une colonne verbe dans la joblist, qui precise la methode a utiliser et faire le dispatch dans backup_process.
[^] # Re: Formation
Posté par Zenitram (site web personnel) . Évalué à 4.
M'en fou : tu dis que c'est lisible, je te répond que non (suffit de regarder la commande sed…)
Non : la commande sed est juste incompréhensible, comment faire évoluer facilement un truc incompréhensible (et non commenté)?
Tu évites soigneusement de parler de l'imbitabilité de ta commande sed…
On parlait de code clair et lisible à la base, ton "argument" (ha ha ha).
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 2.
Je te dis que c'est lisible, j'argumente. Tu reponds non en donnant de mauvais arguments, car la commande sed n'est pas le shell et n'a rien a voir avec.
Mais bon, moi je m'en fous je n'ai rien a prouver a personne et si tu veux continuer a vivre enferme dans des prejuges superficiels, je ne perds rien.
Pour la bonne raison que ca n'a rien a voir avec la programmation en shell.
Si la commande
sedne te plait pas, tu peux en utiliser une autre.[^] # Re: Formation
Posté par freem . Évalué à 1.
Si je comprend bien, le "mocking", c'est l'art de déboguer à coup d'affichage intempestif? Dans ce cas, navré, mais il va falloir que tu changes ta définition de "facile à déboguer", le debug à coup d'affichage, et donc de modif du code, c'est la pire façon de déboguer qui soit, le dernier recours.
Si ce n'est pas ça, je veux bien que tu expliques ce qu'est le mocking, parce que dans ce cas ça m'intéresse.
[^] # Re: Formation
Posté par barmic . Évalué à 4.
En fait il veut dire que tu peut tester chaque méthode séparément, parce qu'elles ont des entrées et des sorties bien définies (tu peut forger les entrées de tes fonctions).
Pour le debuging de script shell, l'option
-xest utile sans être génial. bash permet de faire untrapen DEBUG pour exécuter du code après chaque instruction ça peut être pratique aussi (jamais essayé mais tu peut peut être mettre unreadpour faire une pause à chaque fois). Tu peux aussi mettre des fonctions pour remplacer tes pipes par des pipes avecteepour mieux voir ce qui se passe.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à 0.
Merci pour les infos.
L'option "-x" ne sert qu'a afficher la commande exécutée, c'est ça? (man bash ne dis rien au sujet de cette option)
Enfin, on est loin d'un réel débogage tout de même.
[^] # Re: Formation
Posté par barmic . Évalué à 3.
Ça montre les commandes (réelles) et les sous shell créés.
Je en dis pas le contraire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 3.
C'est exactement ca.
Cette organisation permet aussi de creer facilement les tests unitaires, en comparant avec
diffla sortie attendue de la sortie produite.C'est exactement ca. :-)
Elle sert surtout a deboguer les utilisations de
evalet les remplacements (string interpolation), mais si on a besoin de plus que "jeter un coup d'oeil" il vaut mieux ecrire un petit test unitaire.[^] # Re: Formation
Posté par freem . Évalué à 1.
Du coup, vous utilisez quoi pour faire des TU sur shell? Juste un autre script qui appelle la fonction, ou des outils plus chiadés?
[^] # Re: Formation
Posté par barmic . Évalué à 3.
Il y a différents shunit, shunit2. Ils n'ont rien de bien révolutionnaires, ils (du moins tout ce que j'ai pu voir) se contentent d’exécuter des méthode préfixées par
test_et de mettre à disposition des assertions.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par freem . Évalué à 1.
Déjà pas mal je suppose. Merci pour les tuyaux.
[^] # Re: Formation
Posté par xcomcmdr . Évalué à -1. Dernière modification le 06 août 2014 à 13:31.
HAHAHAHAHAHAHA.
Trop drôle ta blague.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Formation
Posté par zul (site web personnel) . Évalué à 2.
C'est sûr que la version systemd est beaucoup plus simple, mais gère t'elle vraiment la même chose que le script que tu nous montre ? (rotate, ulatencyd clear ALL …).
En plus, ce script est bien documenté, bien indenté, réutilise des fonctions "standards" (pour l'init dudit système). Bref, pas grand chose à lui reprocher.
[^] # Re: Formation
Posté par freem . Évalué à 1.
Rien n'est reproché au script lui-même, qui est effectivement relativement lisible, pour du shell.
Maintenant, un extrait au hasard:
J'ai quelques vagues notions de shell, par exemple je sais que [] est l'équivalent de l'appel à "test". Bon, c'est plus court à taper, et quand on sait que ça veut dire un test, ça va. Enfin, ça va, tant qu'il n'y à pas de "-eq", "-z" ou autre joyeusetés.
Ensuite, bon, la technique d'utiliser l'opérateur logique AND en lieu et place d'un if, c'est cool, tous les dev et admin linux confirmés doivent savoir s'en servir, mais c'est pas aussi trivial que ça.
Dernier point, pourquoi l'auteur a-t-il mis deux ";" à la suite à chaque ligne?
Autrement dit, 9 lignes, 3 WTF pour un curieux qui débarquerait sous Linux et souhaiterais apprendre. Je ne parlerais pas du fait que le langage est incohérent, bien sûr: "if/fi", "case/esac", "for/do/done"? Je ne suis pas sûr pour les while, je ne les ai jamais utilisés, mais j'imagine que c'est similaire à for… Ah, ben du coup je viens de tilter, l'écriture à la con en inversé, c'est juste pour les sauts conditionnels? WTF!
Et puis la, on à du bol, il n'y à pas mixes de chaînes de caractères, ces fameux mixes qui me donnent souvent un mal de chien: "" et '', surtout quand il faut faire appel à des outils tiers qui utilisent eux aussi ce genre de joyeusetés.
[^] # Re: Formation
Posté par wismerhill . Évalué à 1.
C'est la syntaxe du case qui est comme ça, les instructions d'un "cas" doivent se terminer par un double-point-virgule (bash fourni des variantes comme extensions).
[^] # Re: Formation
Posté par freem . Évalué à 1.
Merci, je ne le savais pas. Ça me sera toujours utile un jour ou l'autre.
Mais bon, c'est bien ce que je dis: WTF! Un coup on mets 2 ";", un coup on en mets qu'un. Un coup on écrit une fin de bloc en faisant un miroir d'un mot-clé, un coup on utilise do/done en guise de début/fin de bloc…
Bref, ce "langage simple" ne l'est pas tant que ça, soyons réalistes.
Après, c'est sûr, si on demande à un connaisseur, ça lui semble simple. Après tout, lire et écrire du C++ ne me dérange pas plus que ça, alors je pourrais dire que c'est simple, mais soyons réaliste, ça ne l'est pas, même si ça me semble l'être.
Bah pareil pour shell.
Pour en revenir à shell (qui est le sujet de discussion, C++ n'était qu'un exemple, j'aurai pu prendre lisp, mais j'aurai été emmerdé pour citer des cas de syntaxes subtilement casse-pied, si on me les demande), je peux aussi citer les subtiles différences entre
fooet $( foo ). Parce que je suis sûr qu'il y en a, même sans les connaître. Il y a aussi la gestion des chaînes de caractère, et pas mal de trucs qui deviennent rapidement complexes.J'aimerai tant que les aficionados du shell comprennent que ce n'est pas un langage simple… ce qui ne signifie pas que c'est pas un mauvais langage, bien entendu. Il est efficace pour ce pour quoi il à été conçu après tout.
Et sur ce point très précis, systemd lui est supérieur.
[^] # Re: Formation
Posté par ariasuni . Évalué à 2.
Ce n’est pas parce que tout administrateur système doit connaitre le shell que:
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par Michaël (site web personnel) . Évalué à 5.
Le shell n'est pas moderne, c'est un fait. Par contre du cote de la lisibilite, les deux fonctions principales du shell sont
a. executer un programme, disons
prog, cela ce fait en ecrivantprogb. faire traiter la sortie d'un programme par un autre, disons
prog1etprog2, cela se fait en ecrivantOn peut dire que les concepteurs ont fait l'effort de rendre les deux fonctions principales plutot claires et lisibles.
Ensuite une propriete importante pour la clarte est
c. les fonctions definies par l'utilisateur ont (autant que possible) le meme statut que les programmes externes, c'est-a-dire qu'on les appelle de la meme facon et qu'on peut les combiner avec le
pipe.Et a, b, c, et bien il y a environ 0 autres langages de programmation mainstream qui le permettent.
Donc on fait on peut surtout conclure, qu'aucune des alternatives proposant 1, 2, 3 n'a reussi a s'imposer (l'exemple majeur etant tcl, cf. http://wiki.tcl.tk/17419) et que le shell reste le standard de facto en la matiere.
[^] # Re: Formation
Posté par ariasuni . Évalué à 2.
Certes, mais dans quels cas ce comportement est pratique? Quand on veut faire un truc vite, dans mon cas la ligne de commande ou un script shell très court. Je dis ça parce que j’ai l’impression que dès qu’on commence à faire un truc un peu long, ça devient vite infernal parce que le reste de la syntaxe de Bash est chiante.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Formation
Posté par freem . Évalué à 1.
Perl ne le permets pas? (c'est une vraie question)
[^] # Re: Formation
Posté par barmic . Évalué à 4. Dernière modification le 07 août 2014 à 11:32.
Pas aussi bien. Il peut avoir une syntaxe à la pipe (mais qui se lie à l'envers, mais les appels de programmes externes ne sont pas aussi agréables (et tu n'a pas la parallélisation).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formation
Posté par zurvan . Évalué à 0.
La dépêche ne parle pas de ça, et moi non plus, je parlais juste des messages et des commandes de contrôle en ligne de commande.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Et les scripts ?
Posté par Christophe B. (site web personnel) . Évalué à 5. Dernière modification le 02 août 2014 à 17:45.
Merci pour ces infos … mais une question ne cesse de me démanger :
a quoi ressemble un script systemd pour le démarrage / arrêt d'un service "lambda"
d'après ce lien c'est pas trop éloigné des bon vieux scripts du XXème siècle, plus verbeux mais bon …
faut vivre avec son temps …
[^] # Re: Et les scripts ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 10. Dernière modification le 03 août 2014 à 09:20.
Ce qui m'intéresse, c'est de savoir comment créer un service et le lancer au démarrage.
J'espère que l'un des prochains épisodes me l'expliquera.
En attendant, ces articles arrivent à me réconcilier avec systemd et même à me le faire apprécier.
De plus le lire en français rend la compréhension beaucoup plus facile. Un grand merci aux rédacteurs.
[^] # Re: Et les scripts ?
Posté par Pi3R1k . Évalué à 9. Dernière modification le 02 août 2014 à 20:53.
Pour apache par exemple :
rien de bien fou.
un petit
systemctl enable mon_servicepour l'activer au démarrage.[^] # Re: Et les scripts ?
Posté par Sygne (site web personnel) . Évalué à -3.
Reste à savoir ce qui se cache sous /usr/bin/apachectl…
[^] # Re: Et les scripts ?
Posté par wismerhill . Évalué à 6.
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/support/apachectl.in?view=markup
[^] # Re: Et les scripts ?
Posté par wilk . Évalué à 2.
Ca ressemble à une conf de supervisor. Quelles sont les différences entre les deux (au niveau lancement de services) ?
Est-ce qu'on trouve l'équivalent de superlance, qui permet de tester une connection à un service, sa mémoire occupée… et de le relancer au besoin ?
[^] # Re: Et les scripts ?
Posté par Anonyme . Évalué à 2.
supervisor n'est pas nécessairement adapté pour lancer des taches déjà daemonisées mais plus pour daemoniser des taches en premier plan. C'est la principal différence que je lui trouve avec systemd, il est surtout utile pour bricoler des services.
# Journald
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
Je serais pas contre un tuto sur journald, pour l'instant ça m'encombre plus qu'autre chose ce truc (et la première chose qui m'a fait m'interroger sur la pieuvre systemd, enthousiaste que j'étais). Je l'ai désactivé car en cas de coredump il paralysait complètement le système en monopolisant le disque dur et la RAM, c'était ingérable et menait invariablement à un redémarrage à chaud. Je sais que c'est systemd-coredump qui gère le truc, mais du coup c'était journalisé et c'était la merde. Et même lorsqu'il ne se passe rien, son occupation des ressources est non négligeable par rapport à un bon vieux syslog.
[^] # Re: Journald
Posté par xcomcmdr . Évalué à 4.
Chez moi il ne consomme rien du tout, même sur un vieux Pentium 3…
tu peux dire à systemd-coredump de faire comme avant systemd/journald.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Journald
Posté par Maclag . Évalué à 4.
Ca m'étonnerait que ce soit censé consommer autant de ressources.
C'est peut-être un bug que tu viens de dénicher, ça vaut peut-être le coup de creuser un peu et de remonter l'info.
[^] # Re: Journald
Posté par claudex . Évalué à 6.
Si le coredump est énorme, ça ne m'étonne pas plus que ça. Par contre, ça me semble bizarre que ce soit activé par défaut (ça ne me semble pas utile à la plupart des installations).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Journald
Posté par Frédéric Massot (site web personnel) . Évalué à 5.
Si tu ne veux pas avoir les logs de journald écrit sur ton disque, il te suffit de supprimer le dossier "/var/log/journal".
Extrait de la page man de journald.conf (fichier de conf /etc/systemd/journald.conf) :
Storage= Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer or a syslog daemon will still work however. Defaults to "auto".
En clair si dans le fichier "/etc/systemd/journald.conf" la directive "Storage" n'est pas définie ou est définie à "auto", alors le journal n'est écrit sur le disque que si le dossier "/var/log/journal" existe.
[^] # Re: Journald
Posté par ianux (site web personnel, Mastodon) . Évalué à 3.
Oui, déjà fait, je suis revenu à syslog-ng.
# Excellente initiative !
Posté par Médéric RIBREUX (site web personnel) . Évalué à 10.
Je tiens à souligner que cette série d'articles est une excellente initiative.
En effet, qu'on le veuille ou non systemd va toucher de plus en plus de systèmes car c'est maintenant, le système d'init retenu par la grande majorité des distributions GNU/Linux (dont la prochaine version de Debian stable notamment). D'un point de vue personnel, j'ai tout un tas de machines qui vont être concernées aussi, plus je connaîtrais ce composant, mieux ce sera; ne serait-ce que pour pouvoir mieux me dépatouiller lorsque que je ferais un apt-get install systemd.
Dans ces conditions, je pense qu'à l'avenir, la connaissance de systemd va être un pré-requis pour tout administrateur système digne de ce nom (qu'il considère systemd comme opérationnel ou non). Dans tous les cas, ça ne peut être qu'un plus sur un CV…
Vivement la suite…
[^] # Re: Excellente initiative !
Posté par sebas . Évalué à 10.
Curriculum-vitaed ?
[^] # Re: Excellente initiative !
Posté par reynum (site web personnel) . Évalué à 5.
Nan Curriculum-vitae.service
kentoc'h mervel eget bezan saotred
# Par curiosité
Posté par FantastIX . Évalué à 5.
Pourquoi a-t-on x/y/machin.service et v/w/truc.task plutôt que x/y/services/machin et v/w/tasks/truc, par exemple?
[^] # Re: Par curiosité
Posté par wismerhill . Évalué à 6.
Parce que les répertoire sont utilisés pour autre chose. Par exemple ajouter des dépendances à certains services, ou (avec une version suffisamment récente) ajouter des options à un service sans écraser celles déjà présentes.
[^] # Re: Par curiosité
Posté par FantastIX . Évalué à 3.
Pourrais-tu développer? Je ne comprends pas ce que tu veux dire. Aurais-tu un exemple? Si j'ai compris, un répertoire possède une fonction logique unique avec systemd?
[^] # Utilisation des répertoires
Posté par Sylvain Blandel . Évalué à 10. Dernière modification le 04 août 2014 à 11:04.
Pré-requis : les fichiers
.servicefournis par le gestionnaire de paquets sont dans le répertoire/lib/systemd/system/. Les personnalisations réalisées par l'administrateur sont dans le répertoire/etc/systemd/system/Utiliser des répertoires pour ajouter des dépendances à un service.
Tu souhaites que
machin.servicedépende detruc.service(c'est-à-dire que le lancement demachin.servicelance automatiquementtruc.service). Pour se faire, tu as deux méthodes :La première méthode est de recopier le fichier
machin.servicedans le répertoire/etc/systemd/system/puis d'éditer la copie. Tu ajoutes une ligne « Wants » :
Cette méthode présente malheureusement un inconvénient : si ton gestionnaire de paquets met à jour le fichier
machin.service(dans/lib/systemd/system/), c'est toujours l'ancienne version du fichier (que tu as recopiée dans/etc/systemd/system/) que tu utiliseras.Pour résoudre ce problème, on utilise une seconde méthode, basée sur les répertoires. On crée un répertoire
/etc/systemd/system/machin.service.wants/, et on y met un lien symboliquetruc.servicequi pointe verstruc.service. Ça donne ceci :De cette façon, le lancement de
machin.serviceimplique le lancement detruc.service.Utiliser des répertoires pour ajouter des options à un service (sans écraser les options déjà présentes)
Tu souhaites ajouter 3 options au service bidule. Crée le répertoire
/etc/systemd/system/bidule.service.d/. Dans ce répertoire, tu crées un fichierperso.confqui contiendra les 3 options en question :Ces options se superposeront à celles contenues dans le fichier
bidule.service(qui est dans le répertoire/lib/systemd/system/).Pour conclure : remarquez qu'il est possible d'utiliser les fichiers de personnalisation pour créer des dépendances entre services. Pour le service
zouzou.service, ça donnerait ceci :Dans ce cas, le lancement de
zouzou.serviceimplique le lancement debiscotte.serviceettartine.service. De plus,zouzou.serviceest lancé aprèsbiscotte.serviceet avanttartine.service.[^] # Re: Par curiosité
Posté par Misc (site web personnel) . Évalué à 10.
En fait, c'est assez simple.
Un des soucis non résolu de sysvinit etait le fait que tout etait dans /etc/init.d, marqué (dans les distributions rpms) comme fichier de configuration. Et donc, la moindre modif impliquait de perdre le nouveau fichier à l'update et donc de passer à coté de corrections de bugs ( parfois ).
Avec l'utilisation d'un fichier declaratif à la place d'un fichier qui est un script, on peut mettre au point un algo de fusion de 1 ou plusieurs fichiers servent à décrire une unité de ta configuration ( genre un service, etc, unité au sens large, pas au sens systemd )
Du coup, on peut faire la chose suivante. Dans un repertoire, tu as le fichier fourni par upstream ( distribution, etc ) et dans un autre, tu as le fichier modifié par l'admin. Tu peux faire ça en ecrasant le fichier ( cad toto.service dans les 2 ) et on prends que le fichier de l'admin. Ou on peut utiliser la drop-in configuration, cad faire un repertoire toto.service.d/ avec un fichier foo.conf qui contient un fragment du fichier, et on fusionne les 2 clés par clé, en donnant la priorité à la clé dans le repertoire pour l'admin. Par exemple, je veux rajouter PrivateTmp=yes sur un service, je peux, et de tel sorte que ça soit résistant à l'upgrade, visible ( cad via ls, ou juste via les commandes comme systemctl ) et "config management friendly" ( vu qu'il s'agit juste de déposer un fichier dans un repertoire ).
Du coup, tu as /etc/systemd/system , /usr/lib/systemd/system et /run/systemd/system/ . La section "Unit Load path" de la page de man systemd.unit(5) explique les régles de priorités.
[^] # Re: Par curiosité
Posté par FantastIX . Évalué à 5.
Merci Sylvain et Misc pour ces éclaircissements. Je comprends un peu mieux ce que systemd apporte par rapport à sysvinit (j'espère). Cependant j'ai toujours du mal à voir en quoi ça aurait empêché quelque chose comme services/machin, services/machin.d, services/machin.d/wants et, pour les fichiers de configuration, services/machin.conf ou services/machin.d/machin.conf ou services/conf.d/machin.
[^] # Re: Par curiosité
Posté par Misc (site web personnel) . Évalué à 7.
Sans préciser la sémantique que tu mets sur chaque fichier et repertoire, je suis pas sur de te répondre.
Ensuite, empecher, non, pas plus qu'il y a aucune raison technique qui fait qu'on ne puisse pas écrire les fichiers à l'envers. C'est juste qu'il y à un moment des choix à faire ( genre nommer les concepts, etc ). Le but est pas non plus de supporter toutes les syntaxes qu'une personne peut trouver, mais comme dit plus haut, tu peux le faire via les generateurs, c'est comme ça que le support de sysv est fait de nos jours. Le generateur est un soft qui va lire chaque fichier sysv init et faire une unité systemd à la volée dans /run lors du démarrage. Donc tu peux faire ta syntaxe et la convertire au format que systemd attends sans souci.
[^] # Re: Par curiosité
Posté par Pseudo007 . Évalué à 2.
Par vraiment. Normalement pour les fichiers de config, rpm crée un fichier .rpmnew si l'ancien fichier de configuration a été modifié .
À l'admin d'intégrer manuellement les modifs du nouveau fichier de configuration livré par rpm.
Je fais toujours une copie des fichiers de configuration que je modifie. S'il y a une modif par la distribution, je peux faire un diff.
[^] # Re: Par curiosité
Posté par barmic . Évalué à 5. Dernière modification le 05 août 2014 à 13:30.
Sur les systèmes dérivés de Debian, il demande de résoudre le conflit. Mais Debian cherche à limité au maximum ce genre de choses et la plupart des actions demandent plutôt à aller taper dans
/etc/defaultset les scripts d'init se basent là dessus.Si vraiment tu veux modifier un fichier système (normalement géré par apt/dpkg) tu peut utiliser les diversions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Par curiosité
Posté par claudex . Évalué à 3.
Oui mais non, si tu veux ajouter l'équivalent de
PrivateTmp=true(par exemple) dans Debian et que le l'init.d ne le prévoit pas, tu peux écrire ce que tu veux dans le/etc/default, ça ne changera rien.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Par curiosité
Posté par barmic . Évalué à 4.
Où est-ce que j'ai dis que ça couvrait tous les usages ? Le fait que ce soit limité n'empêche pas de dire que ça existe.
Pour le cas spécifique du PrivateTmp, tu dois pouvoir te démerder avec les diversions pour faire un wrapper aux scripts d'init qui fait le job (mais c'est très crade).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Réutilisation des scripts SysVinit
Posté par Sylvain Blandel . Évalué à 9.
Systemd permet également de réutiliser les scripts SysVinit existants, voir ce tutoriel : Utiliser un script SysVinit avec systemd.
Si on doit déployer systemd, cela permet de parer au plus pressé : faire fonctionner le système. Plus tard, on peut prendre le temps de remplacer les scripts SysVinit par des fichiers
.servicequi utiliseront les nombreuses options que propose systemd (premier lien, second lien, troisième lien).# Un système tellement simple…
Posté par Anthony Jaguenaud . Évalué à -10.
qu’il faut un tuto aussi long pour les administrateurs.
On va encore me targuer de réfractaire, de rétrograde, mais depuis des mois on nous explique que grâce à systemd tout sera tellement simple qu’il une dépêche aussi longue qu’une dépêche sur le noyau pour expliquer basiquement comment ça marche… j’attends avec impatience la prochaine pour l’utilisateur avancé ;-)
[^] # Re: Un système tellement simple…
Posté par Zenitram (site web personnel) . Évalué à -2.
Toi, tu es du genre à dire que 100 pages c'est pas simple, en oubliant comme par hasard qu'avant il fallait 1000 pages…
Motivé à faire le même tuto pour la même chose avec ton init préféré? Enfin, si c'est possible avec ton init préféré.
Oui, surtout vu la façon de critiquer… Toujours aussi percutants les arguments des anti-systemd!
[^] # Re: Un système tellement simple…
Posté par freem . Évalué à 2.
Ne mets pas toutes les personnes qui n'apprécient pas systemd dans le même sac s'il te plaît. Il est possible que j'échoue à ça, mais j'essaie de rester objectif, et j'accorde même un certain nombre d'excellents points à systemd.
[^] # Re: Un système tellement simple…
Posté par xcomcmdr . Évalué à 5.
Ah tiens, et maîtriser SysV ET le shell ça se fait en une demi-journée, je présume ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un système tellement simple…
Posté par cosmocat . Évalué à 7.
lol! La moitié du tuto ce sont des sorties consoles…
# Et Unix la dedans ?
Posté par Anonyme . Évalué à 0.
Je comprends pas la fait qu'aucun n'ai relevé la paternité de SUN Solaris 10 dans cette gestion de démarrage des services.
J'ai utilisé Solaris 10 dès sa sortie (avec ZFS) et je me suis cogné a SMF intégrant le fameux svcadm. Effectivement il faut apprendre a utiliser/configurer, mais le principe des milestones qui me semblait délirant au début m'est apparu comme magique !
Forcement, tu démarres pas un serveur web si ton appli ne tourne pas, mais mieux ! tu lances pas ton appli si ta DB elle tourne pas… Bref, les dépendances au début c'est bien chiant mais c'est diablement efficace.
Alors je vois des gars qui trollent parce que des distributions Linux vont utiliser un truc qui a bientôt 10 ans. Faut évoluer les gars …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.