[systemd]Impressions+Questions(résolu)

[widapit]

Salut tous !!

Alors voilà, je crée ce topic surtout pour soumettre quelques questions que je me pose suite au passage en full Systemd sur une machine test...
Mais je vais en même temps en profiter pour placer mon avis par rapport aux réactions que l'on voit depuis quelques jours sur les différents topics sur le sujet...
Eh oui, notre chère distrib évolue, mais il ne faut pas avoir peur du changement, eh ho, on est en rolling-release quand même !!!

Tout d'abord, niveau install/configuration, j'ai pas trouvé ça moins KISS, c'est pas plus compliqué, juste différent...
à la limite je trouves que sur certaines actions, c'est peut-être moins intuitif mais déjà c'est qu'une impression personnelle et puis aussi surement une question d'habitude...
En revanche, +1 pour cette manière de pouvoir gérer/surveiller les services, ça me plait bien,je me dis que ça va être bien agréable sur un serveur ou il y en a pas mal de lancés !
N'ayant pas beaucoup de daemons à lancer sur cette machine-test et étant donné qu'elle est pas toute jeune, je n'ai pas remarqué de gain significatif sur la vitesse au boot, par contre j'ai pu observer une rapidité accrue lors de l'extinction ...
Faisant pourtant parti de ceux qui redoutaient réellement de se retrouver sans ce bon et loyal /etc/rc.conf, je dois dire qu'à ma grande surprise, je pense que je vais assez facilement me faire à systemd (pour le peu que j'en ai vu pour le moment en tout cas) .

Bon maintenant, les questions :
- Dans ma ligne des daemons, j'avais syslog-ng et crond comment cela est-il géré à présent ?
- Où est trouvé l'info correspondant à "TIMEZONE", je ne l'ai pas vu dans les fichiers (j'utilisais hwclock, lancé depuis les daemons du /etc/rc.conf), pourtant mon syteme est à l'heure, donc ça ne me pose pas de problème, mais c'est juste pour savoir...
- Qu'en est-il de la gestion du lancement des daemons en background ou pas ? et de l'ordre de lancement de ces daemons ?
exemple: sur ma passerelle, il faut absolument que le daemon précédent soit complètement disponible avant de lancer le suivant et (donc) respecter l'ordre : iptables, net-profiles, snort, sshd, named, privoxy .
Comment pourrai-je définir ce comportement ?
- J'ai un petit script dans un /etc/rc.local, mais si j'ai bien compris, ce fichier sera toujours pris en compte, non ?

Merci.

[FoolEcho]

Eh oui, notre chère distrib évolue, mais il ne faut pas avoir peur du changement, eh ho, on est en rolling-release quand même !!!

Tout d'abord, niveau install/configuration, j'ai pas trouvé ça moins KISS, c'est pas plus compliqué, juste différent...

+1.
Le "tort" des devs actuels est de ne pas trop expliquer pourquoi systemd ne va tuer Arch, pourquoi initscripts va continuer de vivre, que le rc.conf n'est pas mort, etc.. (mais bref, y a d'autres sujets pour ça).

- Dans ma ligne des daemons, j'avais syslog-ng et crond comment cela est-il géré à présent ?

Il faut établir ces services au démarrage (sytemctl enable). syslog-ng.service et pour cron, selon la mise à oeuvre installée: cronie.service, dcron.service, etc..
Il faut cependant configurer syslog pour passer par systemd, de cette manière tu as les mêmes logs qu'avant: kernel, errrors, etc.. Si tu as logrotate, il continuera alors son boulot son problème (sinon, pas de log, pas d'archivage): https://wiki.archlinux.org/index.php/Sy ... md_Journal.
Comme indiqué dans le wiki aussi, on peut ne pas lancer syslog-ng et se contenter de créer /var/log/journal pour stocker les différents journaux (sinon ils disparaissent entre deux démarrages).
En test aussi, j'ai mis les deux journaux en parallèle le temps de me repérer (comment récupérer/filtrer les mêmes logs directement depuis systemd).

- Où est trouvé l'info correspondant à "TIMEZONE", je ne l'ai pas vu dans les fichiers (j'utilisais hwclock, lancé depuis les daemons du /etc/rc.conf), pourtant mon syteme est à l'heure, donc ça ne me pose pas de problème, mais c'est juste pour savoir...

/etc/timezone

- Qu'en est-il de la gestion du lancement des daemons en background ou pas ? et de l'ordre de lancement de ces daemons ?
exemple: sur ma passerelle, il faut absolument que le daemon précédent soit complètement disponible avant de lancer le suivant et (donc) respecter l'ordre : iptables, net-profiles, snort, sshd, named, privoxy .
Comment pourrai-je définir ce comportement ?

Là, je ne saurai pas te répondre. Mais l'intérêt de systemd est justement de lancer les services lorsqu'il est possible de le faire donc je pense que ça se fait automatiquement (ce qui peut ne pas plaire). Mais je ne fais que supposer .
À vérifier auprès des habitués (tuxce ?) donc (j'avoue que ma préoccupation pour la semaine est le journal... après avoir vérifié que tous les services étaient lancés).

- J'ai un petit script dans un /etc/rc.local, mais si j'ai bien compris, ce fichier sera toujours pris en compte, non ?

Le rc.local n'est lu qu'à la condition d'installer initscripts-systemd (et donc de ne pas être en full systemd, ce qui soit dit en passant est sans doute plus sûr ).

[tuxce]

Le "tort" des devs actuels est de ne pas trop expliquer pourquoi systemd ne va tuer Arch, pourquoi initscripts va continuer de vivre, que le rc.conf n'est pas mort, etc.. (mais bref, y a d'autres sujets pour ça).

Il ne faut pas jeter des trolls comme ça
Le dev qui s'occupe d'initscripts (ainsi que d'autres) a du laisser une centaine de messages dans les différentes ml pour expliquer !
Pour les autres, ce n'est pas encore sur [core] donc c'est normal qu'il n'y ait pas d'annonce officielle.

- Où est trouvé l'info correspondant à "TIMEZONE", je ne l'ai pas vu dans les fichiers (j'utilisais hwclock, lancé depuis les daemons du /etc/rc.conf), pourtant mon syteme est à l'heure, donc ça ne me pose pas de problème, mais c'est juste pour savoir...

Comme dit par FoolEcho, c'est /etc/timezone, par contre, c'est un fichier non compatible avec initscripts, ceci dit, le fuseau horaire, c'est en fait le fichier /etc/localtime qui pointe vers le bon fuseau, une fois ceci fait, que TIMEZONE soit vide pour initscripts ou /etc/timezone inexsistant pour systemd importe peu, l'heure sera au bon fuseau horaire.

- Qu'en est-il de la gestion du lancement des daemons en background ou pas ? et de l'ordre de lancement de ces daemons ?
exemple: sur ma passerelle, il faut absolument que le daemon précédent soit complètement disponible avant de lancer le suivant et (donc) respecter l'ordre : iptables, net-profiles, snort, sshd, named, privoxy .
Comment pourrai-je définir ce comportement ?

Le principe est de lancer tout ce qu'on peut du moment qu'il n'y a pas d'indication contraire.
Par contre, l'interface réseau que t'utilises n'existe pas de base ? Parce que sinon, il n'y a pas besoin d'ordre, sshd ou autres peuvent très bien démarrer sans le réseau.
Pour donner des ordres au lancement, il faut modifier les units après les avoir copier dans /etc/systemd/system. Tu peux te baser sur ceux existants, par exemple, tu trouves:

Code : Tout sélectionner

After=network.target

dans openvpn@.service, donc openvpn ne se lancera qu'après le réseau.

- J'ai un petit script dans un /etc/rc.local, mais si j'ai bien compris, ce fichier sera toujours pris en compte, non ?

+1 pour FoolEcho, je rajouterai juste que tu peux simplement créer un service appelant ton script:

Code : Tout sélectionner

[Unit]
Description=Mon script

[Service]
ExecStart=chemin_script

Après selon ce qu'il fait, tu peux être amené à compléter, mais en théorie un rc.local n'a pas besoin de plus.

[jc51]

bonjour

je voulais savoir si je peux supprimer le paquet systemd-arch-units sachant que j'ai pu initscripts?

[tuxce]

Ce n'est pas lié à initscripts, ce paquet ne contient que des .service de softs n'en procurant pas, à toi de savoir ce que t'utilises dedans.

[FoolEcho]

@jc51: Ce paquet est indépendant de systemd-initscripts. Je ne voudrais pas dire de bétise, mais sa nécessité dépend simplement de si tu utilises ou non des services inclus dedans. Et vu qu'il y a au moins dhcpcd... (en fait, ce paquet regroupe des services qui ne sont pas directement inclus dans les paquets concernés, comme gdm ou udisk).

... grillé.

[jc51]

ok merci pour les réponses.

[widapit]

Oui, merci beaucoup pour les réponses !!

Alors, pour syslog-ng/dcron, (je me doutais des commandes ) -> tests & observations OK pour le moment: j'ai crée le répertoire /var/log/journal et j'ai bien des lignes en date d'aujourd'hui dans mon /var/log/everything.log et autres . Et quand je reboot, je les ai toujours (anciennes et nouvelles!) donc tout à l'air de fonctionner comme avant...

Pour le /timezone je l'avais pas vu parcequ'il ne s'est pas crée (contrairement à /os-release) et je ne l'ai pas crée non plu. Puis tuxce explique le pourquoi avec le fuseau du /localtime, donc c'est bon !

Ensuite pour les daemons:

Par contre, l'interface réseau que t'utilises n'existe pas de base ? Parce que sinon, il n'y a pas besoin d'ordre, sshd ou autres peuvent très bien démarrer sans le réseau.

oui, ok pour sshd (lui écoute partout) c'est parce-que j'ai pris toute la ligne, mais en fait ce qui est important, c'est que iptables soit lancé avant tout, ensuite il faut que les périphériques/interfaces/conf réseau soient opés avant de lancer "snort" et "named" qui font la gueule si ils trouvent pas où écouter tel qu'indiqué dans leurs conf respectives (privoxy aussi il me semble...); et pour ça j'ai besoin de lancer net-profiles qui appele les profils : (Eth_0 Eth_1 Eth2) .
Donc je vais regarder ce que ça donne avec la méthode proposée par tuxce , en passant par /etc/systemd/system

Pour le script, il s'agit juste de quelques tests avant montage d'un volume en LVM .

/etc/rc.local et /etc/rc.local.shutdown sont exécutés respectivement au démarrage et à l'arrêt du système, pour ne pas en tenir compte:

Code : Tout sélectionner

systemctl disable rc-local.service

je suppose que ceci n'est pas valable en full systemd, j'essaierai donc en créant un service appelant le script...

Merci à tous en tout cas !!

[FoolEcho]

Le rc.local n'est lu qu'à la condition d'installer initscripts-systemd (et donc de ne pas être en full systemd,

La partie du wiki que tu cites ne s'applique effectivement qu'avec initscripts-systemd.

[widapit]

ouaip, nickel, j'étais en train de voir ça en installant sur mon poste principal !!
manquait juste une ligne par rapport à ce qu'a indiqué tuxce, le fichier (/etc/systemd/system/monscript.service) se présente donc comme ceci :

Code : Tout sélectionner

[Unit]
Description=description de mon script

[Service]
ExecStart=/chemin/vers/mon-script

[Install]
WantedBy=multi-user.target

par contre, je me confrontes à cpufreq et sensors, qui ne possèdent pas de fichier *.services, cependant sensors me donne des résusltats normaux, alors qu'avant, je l'avais placé dans /etc/rc.conf car sans ça il ne m'affichait qu'une seule ligne, avec la température du bus, et je ne voyais pas les températures des coeurs, maintenant il m'affiche tout, est-ce que ça vient de systemd ou d'une autre mise à jour ??

Pour l'ordre des daemons, je verrais ça plus tard, ma passerelle ne redémarrant pas souvent, (elle est même encore sous grub-legacy, alors que les autres machines sont toutes passées sous syslinux ou grub2) j'ai encore le temps de voir pour ça, je ne vais pas tester de suite et de toutes façons j'ai de quoi faire !
... le reste de mes questions ayant trouvées des réponses, je vais passé en résolu (j'ouvrirai un post plus tard si j'ai vraiment des soucis avec un daemon particulier)

-Merci-

[widapit]

Salut !

Petit retour après quelques jours d'utilisation/observation:
En plus de ce que je relate dans le message précédent par rapport à sensors, j'ai aussi remarqué que dorénavant alsa enregistre tout automatiquement et tout seul
Enfin ce que je veux dire c'est qu'avant il était dans mes daemons du /etc/rc.conf et je devais passer par alsactl store pour que les modifs via alsamixer soient prises en compte après un reboot;
maintenant, sans avoir lancé le daemon et sans faire alsactl store mes modifs étaient tel quelles ce matin à l'allumage !!
c'est plutôt bien, mais pourquoi ces changements ?!
est-ce que ça vient bien de systemd ou d'(une) autre(s) mise(s) à jour ?

[FoolEcho]

c'est plutôt bien, mais pourquoi ces changements ?!
est-ce que ça vient bien de systemd ou d'(une) autre(s) mise(s) à jour ?

Ni l'un, ni l'autre, ça m'étonnerait. Pour ce qui est des services, init ou systemd, même combat (c'est aussi pourquoi il ne faut pas "craindre" systemd). L'un ne fait pas plus de trucs que l'autre (pour systemd c'est l'organisation qui change). Ce qui veut dire que l'un et l'autre vont faire alsactl store/restore (y a qu'à comparer les fichiers de service systemd avec le rc.d). Donc je ne sais pas le pourquoi de ton comportement étrange avec alsa, mais ce n'est probablement pas systemd qui a résolu quoi que ce soit (à moins d'un problème dans le script rc.d... ou un script/configuration parasite ?).

[widapit]

mmh, ok...
je pensais que c'était lié car c'est depuis le passage à systemd que j'ai remarqué ces comportements, en même temps pour sensors et pour alsa !
sinon effectivement il n'y a eu des mises à jour que pour alsa-plugins (09/07 mais je n'avais rien remarqué depuis... les autres alsa datent d'avant la mi-mai) et la dernière de lm_sensors date du 22/06 donc ce n'est pas ça !

y a qu'à comparer les fichiers de service systemd avec le rc.d

ben justement ...

Code : Tout sélectionner

[root@cobaye - 14:07:12 ]# systemctl status alsa.service
alsa.service
 	  Loaded: error (Reason: No such file or directory)
	  Active: inactive (dead)

[root@cobaye - 14:07:20 ]# systemctl status sensors.service
sensors.service
	  Loaded: error (Reason: No such file or directory)
  	  Active: inactive (dead)

???

[FoolEcho]

Les services sont alsa-store.service et alsa-restore.service. Pour sensors, lm_sensors.service ? (et je parlais de comparer le contenu de /usr/lib/systemd/system/alsa-restore.service, alsa-store.service par exemple avec /etc/rc.d/alsa )

[widapit]

oui, j'avais bien compris ça pour les fichiers...
et donc dans le /usr/lib/systemd/system/alsa-store.service il y a cette ligne, ça doit jouer :

Code : Tout sélectionner

Before=shutdown.target

pourtant je ne l'ai jamais lancé du coup et j'ai quand même ça :

Code : Tout sélectionner

[root@cobaye - 16:27:32 ]# systemctl status alsa-store.service
alsa-store.service - Store Sound Card State
	  Loaded: loaded (/usr/lib/systemd/system/alsa-store.service; static)
  	  Active: inactive (dead)
	  CGroup: name=systemd:/system/alsa-store.service

pareil pour lm_sensors (c'est bien lm_sensors.service ), je ne l'ai jamais lancé mais :

Code : Tout sélectionner

[root@cobaye - 16:28:07 ~]# systemctl status lm_sensors.service
lm_sensors.service - Initialize hardware monitoring sensors
	  Loaded: loaded (/usr/lib/systemd/system/lm_sensors.service; enabled)
	  Active: active (exited) since Sat, 28 Jul 2012 10:38:42 +0200; 5h 52min ago
	  Process: 315 ExecStart=/usr/bin/sensors -s (code=exited, status=0/SUCCESS)
  	  Process: 290 ExecStart=/sbin/modprobe -qab $BUS_MODULES $HWMON_MODULES (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/lm_sensors.service

ils sont loaded tout les 2, ce qui explique les résultats...

Merci.

[FoolEcho]

pourtant je ne l'ai jamais lancé du coup et j'ai quand même ça :

Sauf erreur de ma part (je n'ai pas vérifié mais c'est comme ça que j'ai fait sur ma machine de test), c'est parce que tu as probablement fait la transition avec initscripts-systemd avant de basculer sur un full systemd (donc tes services du rc.conf ont été lancés automatiquement via systemd avant la bascule).

[widapit]

bé non !
j'ai attaqué par

Code : Tout sélectionner

pacman -S systemd-arch-units systemd-sysvcompat

qui m'a donc prévenu de la suppression de init-scripts justement et du renommage des fichiers en /rc.*.pacsave, ensuite j'ai édité les fichiers dans /etc
puis j'ai éssayé de lancer un service et j'ai eu un message du style "impossible de contacter Dbus" puis j'ai simplement fait reboot que j'ai du forcer vu qu'arriver dans la dernière phase, il restait bloqué, et ensuite redémarrage, et tout marchait...

[FoolEcho]

Pour le service alsa, ça doit venir du fait que basic.target l'embarque (j'suis comme beaucoup hein, j'découvre ):

Code : Tout sélectionner

$ systemctl show -p "Wants" basic.target
Wants=console-kit-log-system-start.service systemd-tmpfiles-clean.timer alsa-restore.service

Code : Tout sélectionner

$ pacman-color -Qo $(locate alsa-restore.service)
/usr/lib/systemd/system/alsa-restore.service appartient à alsa-utils 1.0.25-3
/usr/lib/systemd/system/basic.target.wants/alsa-restore.service appartient à alsa-utils 1.0.25-3