Admin/Systemd/Brief - Historique des versions

Didier : /* Avantages */

2015-01-30T13:13:28Z

Avantages

← Version précédente		Version du 30 janvier 2015 à 13:13
Ligne 52 :		Ligne 52 :
	* Il existe un mode de démarrage interactif qui permet de confirmer chaque lancement de service en passant au noyau le paramètre « systemd.confirm_spawn=1 ».		* Il existe un mode de démarrage interactif qui permet de confirmer chaque lancement de service en passant au noyau le paramètre « systemd.confirm_spawn=1 ».
	* systemd gère le readahead qui permet d’optimiser les lectures disque au démarrage en pré‐chargeant les blocs qui vont être nécessaires par la suite (en se basant sur un enregistrement d’un démarrage précédent).		* systemd gère le readahead qui permet d’optimiser les lectures disque au démarrage en pré‐chargeant les blocs qui vont être nécessaires par la suite (en se basant sur un enregistrement d’un démarrage précédent).

			== Inconvénients ==

			* Utilisation de programme pour chaque tâche d'administration: gestion des services, lecture des journaux de logs, etc…
			* Systemd est plutôt invasif. Il n’entend pas se contenter de gérer seulement le lancement des démons, mais également de prendre en charge l’authentification, la gestion de l’énergie etc … Ce qui de fait s’oppose quelque peu à la philosophie Unix qui dit qu’il vaut mieux plusieurs petits programmes qui ne s’occupent que d’une tâche à la fois bien, plutôt qu’une pieuvre qui voudrait tout faire mal (« do one thing, but do it well »). Certains l’appellent même le deuxième Kernel.

	== Gestion particulière ==		== Gestion particulière ==

Didier le 30 janvier 2015 à 11:15

2015-01-30T11:15:17Z

← Version précédente		Version du 30 janvier 2015 à 11:15
Ligne 55 :		Ligne 55 :
	== Gestion particulière ==		== Gestion particulière ==

	=== ~~Multiples déclinaisons~~ ===		=== Multi-instances ===

	Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...		Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...
Ligne 61 :		Ligne 61 :
	[[Admin/Systemd\|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.		[[Admin/Systemd\|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.

	client est le nom du fichier de configuration à charger dans <path>/etc/openvpn</path> (sans l'extension .conf)		ex: OpenVPN: client est le nom du fichier de configuration à charger dans <path>/etc/openvpn</path> (sans l'extension .conf)
	systemctl start openvpn@client.service		systemctl start openvpn@client.service

	=== Service ~~fonctionnant avec xinetd~~ ===		=== Service associé à une socket ===

	~~Il est possible de remplacer xinetd par systemd. Le symbole '''@'~~'' à la ~~fin du nom~~ de ~~l'unité de service indique à systemd que le service est démarré par la socket~~.		Certain services nécessite l'écoute préalable sur une socket et ne sont démarrés que lors d'une connexion sur celle-ci, à la manière de inetd/xinetd.

	~~<path>/usr/lib/systemd/system/amanda@~~.service~~</path>~~		ex: git-daemon: Seul l'écoute sur la socket est démarré. Le service associé sera démarré à la connexion. De plus, le service ne peut être démarré manuellement (le fichier unit est un template, il comporte un @ dans son nom)
	~~<pre>~~		systemctl start git.socket
	~~[Unit]~~
	~~Description~~=~~Amanda Backup System~~		== Modification de la configuration d'un daemon ==
	~~After=local~~-~~fs.target~~
			Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande
			<pre>systemctl --system daemon-reload</pre>

	~~[Service]~~		== Lister les services ==
	~~User~~=~~amandabackup~~
	~~Group~~=~~disk~~
	~~ExecStart~~=~~/usr/sbin/amandad -auth~~=~~bsdtcp amdump amindexd amidxtaped~~
	~~StandardInput=socket~~
	~~</pre>~~

	<~~path~~>~~/usr/lib/systemd/system/amanda.socket~~</~~path~~>		Pour lister les services, avec leur état actuel et une brève description (équivalent à <code>chkconfig --list</code>)
	<pre>		<pre>systemctl --full --type=service</pre>
	~~[Unit]~~
	~~Description~~=~~Amanda Activation Socket~~

	~~[Socket]~~		Pour lister les fichiers unit définissant un service sur le système (équivalent à <code>ls /etc/init.d/</code>)
	~~ListenStream~~=~~10080~~		<pre>systemctl list-unit-files --type=service</pre>
	~~Accept=true~~

	~~[Install]~~		== Confinement ==
	~~WantedBy~~=~~sockets.target~~
	~~</pre>~~
	~~Le protocole TCP est ici utilisé. Afin d'utiliser '''UDP''', il faudrait remplacer '''ListenStream''' par '''ListenDatagram'''.~~

	~~Afin~~ de ~~démarrer Amanda~~		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 <app>ps</app> 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.
	~~systemctl start amanda~~.~~socket~~

	~~Démarrage auto~~		Souvent, le seul workaround consiste à regarder l’arbre d’héritage des processus tel qu’il est donné par <app>ps xaf</app>, 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.
	~~systemctl enable amanda~~.~~socket~~

	~~== Modification~~ de ~~la configuration d'~~un ~~daemon ==~~		Avec systemd, chaque processus engendré est placé dans un [[Services/Kernel/CGroup\|groupe de contrôle]] (cgroup) nommé d’après le service. Les [[Services/Kernel/CGroup\|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 [[Services/Kernel/CGroup\|groupe de contrôle]] de leur parent. Quitter un [[Services/Kernel/CGroup\|groupe de contrôle]] n’est pas possible pour un processus sans privilège. C’est pourquoi les [[Services/Kernel/CGroup\|groupes de contrôle]] 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 [[Services/Kernel/CGroup\|groupes de contrôle]] peuvent être utilisés pour tuer proprement un service et tous les processus qu’il a créés, sans exception.

	~~Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande~~		<pre>
	<pre>~~systemctl~~ --system daemon-~~reload~~</pre>		systemd-cgls
			├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
			├─system.slice
			│ ├─avahi-daemon.service
			│ │ ├─1149 avahi-daemon: running [didier.local
			│ │ └─1164 avahi-daemon: chroot helpe
			│ ├─dbus.service
			...
			</pre>

	[[Catégorie:Fedora\|Systemctl]]		[[Catégorie:Fedora\|Systemctl]]

Didier : /* Gestion particulière */

2014-02-09T10:56:04Z

Gestion particulière

@@ Ligne 54 : / Ligne 54 : @@
 == Gestion particulière ==
 Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...
 [[Admin/Systemd|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.
 client est le nom du fichier de configuration à charger dans <path>/etc/openvpn</path> (sans l'extension .conf)
   systemctl start openvpn@client.service
 == Modification de la configuration d'un daemon ==

Didier le 30 septembre 2013 à 13:50

2013-09-30T13:50:54Z

@@ Ligne 2 : / Ligne 2 : @@
 == Gestion basique ==</noinclude>
-[[Admin/Systemd|Systemd]] est un gestionnaire de service. Il permet de les lancer, les arrêter, les relancer, d'en assurer un suivi, etc.
+[[Admin/Systemd|Systemd]] est un gestionnaire de service. C'est le tout premier processus (PID 1) a être lancé et aussi le seul a être lancé par le noyau. Il doit donc assurer toute l’initialisation du système, le lancement des différents services et des systèmes permettant la connexion des utilisateurs. De plus il doit gérer les processus orphelins afin qu'il ne deviennet pas des processus zombies.
 C'est aussi un gestionnaire de session. Il permet l'utilisation du même matériel en passant d'une session (~loging) à une autre sans que cela pose de problème.
 Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.
-C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Systemd/Journalctl|Journalctl]]
+C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Systemd/Journalctl|Journalctl]]. Il a comme avantages:
-[[Admin/Systemd|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.
+[[Admin/Systemd|Systemd]] dispose d'une notion d'unité (unit in english).
 * Démarrage d'un service. C'est l'équivalent de <app>service myservice start</app><pre>systemctl start myservice.service</pre>
 * Arrêt d'un service. C'est l'équivalent de <app>service myservice stop</app><pre>systemctl stop myservice.service</pre>
@@ Ligne 15 : / Ligne 32 : @@
 {{Admon/tip|Actions Systemd|Il existe bien sûr d'autres actions possibles, tel que '''reload''', '''status''', etc...}}
 <noinclude>
 == Gestion particulière ==

Didier le 27 septembre 2013 à 07:43

2013-09-27T07:43:03Z

← Version précédente		Version du 27 septembre 2013 à 07:43
Ligne 6 :		Ligne 6 :
	Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.		Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.

	C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Systemd/Journalctl~~/Brief~~\|Journalctl]]		C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Systemd/Journalctl\|Journalctl]]

	[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.		[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.

Didier le 27 septembre 2013 à 07:37

2013-09-27T07:37:34Z

← Version précédente		Version du 27 septembre 2013 à 07:37
Ligne 6 :		Ligne 6 :
	Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.		Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.

	C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Journalctl/Brief\|Journalctl]]		C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Systemd/Journalctl/Brief\|Journalctl]]

	[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.		[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.

Didier le 27 septembre 2013 à 07:26

2013-09-27T07:26:04Z

← Version précédente		Version du 27 septembre 2013 à 07:26
Ligne 6 :		Ligne 6 :
	Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.		Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.

	C'est le successeur de SysVinit (init System V)		C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec [[Admin/Journalctl/Brief\|Journalctl]]

	[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.		[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.
Ligne 14 :		Ligne 14 :
	* Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app><pre>systemctl disable myservice.service</pre>		* Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app><pre>systemctl disable myservice.service</pre>
	{{Admon/tip\|Actions Systemd\|Il existe bien sûr d'autres actions possibles, tel que '''reload''', '''status''', etc...}}		{{Admon/tip\|Actions Systemd\|Il existe bien sûr d'autres actions possibles, tel que '''reload''', '''status''', etc...}}
			<noinclude>
	<noinclude>== Gestion particulière ==~~</noinclude>~~		== Gestion particulière ==

	Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...		Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...

	[[Admin/Systemd\|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.		[[Admin/Systemd\|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.
	~~<noinclude>~~
	=== OpenVPN ===		=== OpenVPN ===

Ligne 26 :		Ligne 26 :
	systemctl start openvpn@client.service		systemctl start openvpn@client.service

	== Modification de la configuration d'un daemon ==~~</noinclude>~~		== Modification de la configuration d'un daemon ==

	Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande		Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande
	<pre>systemctl --system daemon-reload</pre>		<pre>systemctl --system daemon-reload</pre>
	~~<noinclude>~~
	[[Catégorie:Fedora\|Systemctl]]		[[Catégorie:Fedora\|Systemctl]]
	[[Catégorie:Application\|Systemctl]]		[[Catégorie:Application\|Systemctl]]
	[[Catégorie:Système\|Systemctl]]		[[Catégorie:Système\|Systemctl]]
	</noinclude>		</noinclude>

Didier le 27 septembre 2013 à 07:09

2013-09-27T07:09:28Z

← Version précédente		Version du 27 septembre 2013 à 07:09
Ligne 1 :		Ligne 1 :
	= Gérer les Services avec systemctl =		<noinclude>= Gérer les Services avec systemctl =

	== Gestion basique ==		== Gestion basique ==</noinclude>
			[[Admin/Systemd\|Systemd]] est un gestionnaire de service. Il permet de les lancer, les arrêter, les relancer, d'en assurer un suivi, etc.
			C'est aussi un gestionnaire de session. Il permet l'utilisation du même matériel en passant d'une session (~loging) à une autre sans que cela pose de problème.
			Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.

			C'est le successeur de SysVinit (init System V)

			[[Admin/Systemd\|Systemd]] dispose d'une notion d'unité (unit in english). Les services sont un type d'unité.
	* Démarrage d'un service. C'est l'équivalent de <app>service myservice start</app><pre>systemctl start myservice.service</pre>		* Démarrage d'un service. C'est l'équivalent de <app>service myservice start</app><pre>systemctl start myservice.service</pre>
	* Arrêt d'un service. C'est l'équivalent de <app>service myservice stop</app><pre>systemctl stop myservice.service</pre>		* Arrêt d'un service. C'est l'équivalent de <app>service myservice stop</app><pre>systemctl stop myservice.service</pre>
	* Ajout d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice on</app><pre>systemctl enable myservice.service</pre>		* Ajout d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice on</app><pre>systemctl enable myservice.service</pre>
	* Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app><pre>systemctl disable myservice.service</pre>		* Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app><pre>systemctl disable myservice.service</pre>
	{{Admon/tip\|Actions Systemd\|Il existe bien sûr d'~~autrs~~ actions possibles, tel que '''reload''', '''status''', etc...}}		{{Admon/tip\|Actions Systemd\|Il existe bien sûr d'autres actions possibles, tel que '''reload''', '''status''', etc...}}

	== Gestion particulière ==		<noinclude>== Gestion particulière ==</noinclude>

	Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...		Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...
	~~Systemd implémente pour eux une variable dans le nom du fichier afin de les différencier.~~

			[[Admin/Systemd\|Systemd]] implémente pour eux une variable dans le nom du fichier afin de les différencier.
			<noinclude>
	=== OpenVPN ===		=== OpenVPN ===

Ligne 18 :		Ligne 26 :
	systemctl start openvpn@client.service		systemctl start openvpn@client.service

	== Modification de la configuration d'un daemon ==		== Modification de la configuration d'un daemon ==</noinclude>

	Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande		Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande
	<pre>systemctl --system daemon-reload</pre>		<pre>systemctl --system daemon-reload</pre>
			<noinclude>
	[[Catégorie:Fedora\|Systemctl]]		[[Catégorie:Fedora\|Systemctl]]
	[[Catégorie:Application\|Systemctl]]		[[Catégorie:Application\|Systemctl]]
	[[Catégorie:Système\|Systemctl]]		[[Catégorie:Système\|Systemctl]]
			</noinclude>

Didier le 27 septembre 2013 à 06:15

2013-09-27T06:15:44Z

← Version précédente		Version du 27 septembre 2013 à 06:15
Ligne 1 :		Ligne 1 :
	= ~~Manage~~ Services ~~with~~ systemctl =		= Gérer les Services avec systemctl =

	== ~~Common management~~ ==		== Gestion basique ==
	*~~Start a~~ service		* Démarrage d'un service. C'est l'équivalent de <app>service myservice start</app><pre>systemctl start myservice.service</pre>
	systemctl ~~start~~ myservice.service		* Arrêt d'un service. C'est l'équivalent de <app>service myservice stop</app><pre>systemctl stop myservice.service</pre>
			* Ajout d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice on</app><pre>systemctl enable myservice.service</pre>
			* Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app><pre>systemctl disable myservice.service</pre>
			{{Admon/tip\|Actions Systemd\|Il existe bien sûr d'autrs actions possibles, tel que '''reload''', '''status''', etc...}}

	*Stop a service		== Gestion particulière ==
	~~systemctl stop myservice.service~~

	*Add a service to run at boot		Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...
	~~systemctl enable myservice~~.~~service~~		Systemd implémente pour eux une variable dans le nom du fichier afin de les différencier.

	== ~~Particular management~~ ==		=== OpenVPN ===

	~~=== OpenVPN ===~~		client est le nom du fichier de configuration à charger dans <path>/etc/openvpn</path> (sans l'extension .conf)
	client ~~is the name of config file on~~ /etc/openvpn (~~without~~ extension .conf)
	systemctl start openvpn@client.service		systemctl start openvpn@client.service

			== Modification de la configuration d'un daemon ==

			Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande
			<pre>systemctl --system daemon-reload</pre>

	[[Catégorie:Fedora\|Systemctl]]		[[Catégorie:Fedora\|Systemctl]]
	[[Catégorie:Application\|Systemctl]]		[[Catégorie:Application\|Systemctl]]
	[[Catégorie:Système\|Systemctl]]		[[Catégorie:Système\|Systemctl]]

	~~== Modify daemon configuration ==~~

	~~# Edit file <path>/usr/lib/systemd//.service</path>~~
	~~# Reload system config <pre>systemctl --system daemon-reload</pre>~~

Didier : Page créée avec « = Manage Services with systemctl = == Common management == Start a service systemctl start myservice.service Stop a service systemctl stop myservice.service *Add a ... »

2013-01-20T09:53:53Z

Page créée avec « = Manage Services with systemctl = == Common management == *Start a service systemctl start myservice.service *Stop a service systemctl stop myservice.service *Add a ... »

Nouvelle page

= Manage Services with systemctl =

== Common management ==
*Start a service
systemctl start myservice.service

*Stop a service
systemctl stop myservice.service

*Add a service to run at boot
systemctl enable myservice.service

== Particular management ==

=== OpenVPN ===
client is the name of config file on /etc/openvpn (without extension .conf)
systemctl start openvpn@client.service

[[Catégorie:Fedora|Systemctl]]
[[Catégorie:Application|Systemctl]]
[[Catégorie:Système|Systemctl]]

== Modify daemon configuration ==

# Edit file <path>/usr/lib/systemd/*/*.service</path>
# Reload system config <pre>systemctl --system daemon-reload</pre>