Home
admin
|
SystemD October 18th, 2016 |
|||||||||||||||||||||||||||||||||||||||||||||
- units vs unit-files - Target - Journaux - [Service] Section - [Unit] Section - [Install] Section - Scripts - De la doc ? - Divers - Et le fichier inittab ? - Démarrage interactif
list-units command only displays units that systemd has attempted to parse and load into memory. Since systemd will only read units that it thinks it needs, this will not necessarily include all of the available units on the system. list-units : unités chargées et actives list-units -a : unités chargées mais inactives To see every available unit file within the systemd paths, including those that systemd has not attempted to load, you can use the list-unit-files command instead. Exemple d'un système pour lequel le firewall n'est pas activé. L'unité n'est pas chargée et active
L'unité n'est pas chargée et inactive
L'unité existe cependant sur le système :
On peut la charger :
Source : https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units
 Lists currently loaded target units.
Changes the current target
Default runlevel
Le runlevel par défaut est défini ainsi :
ce qui peut se vérifier :
Note : to set the default target, use the command systemctl set-default targetname.target. targetname can be, among others: rescue.target multi-user.target graphical.target reboot.target
 Type=
[...] Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units. RemainAfterExit= is particularly useful for this type of service. This is the implied default if neither Type= or ExecStart= are specified. [...] RemainAfterExit=
Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. Source : http://www.freedesktop.org/software/systemd/man/systemd.service.html
Requires=¶
Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services. Note that dependencies of this type may also be configured outside of the unit configuration file by adding a symlink to a .requires/ directory accompanying the unit file. For details see above. Wants=
A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit. Note that dependencies of this type may also be configured outside of the unit configuration file by adding symlinks to a .wants/ directory accompanying the unit file. For details, see above. Source : http://www.freedesktop.org/software/systemd/man/systemd.unit.html
"This section is not interpreted by systemd(1) during runtime. It is used exclusively by the enable and disable commands of the systemctl(1) tool during installation of a unit" Source : http://www.freedesktop.org/software/systemd/man/systemd.unit.html WantedBy=, RequiredBy=
This option may be used more than once, or a space-separated list of unit names may be given.
This has the effect that a dependency of type Wants= or Requires= is added from the listed unit to the current unit. The primary result is that the current unit will be started when the listed unit is started.
Où sont les scripts
Dans /lib/systemd/system (<=> /usr/lib/systemd/system)  Si vous voulez en ajouter, il faut le faire dans /etc/systemd/system
Ils ressemblent à quoi les scripts ?
Notes : Unit files are built from several configurable sections, including unit descriptions and dependencies. Systemd also allows administrators to explicitly define a service's dependencies and load them before the given service starts by editing the unit files. Each unit file has a line that starts After= that can be used to define what service is required before the current service can start. WantedBy=lines specify that a target requires a given unit. Exec format error
Solution : ne pas oublier le shebang en début de script...
https://www.alionet.org/content.php?194-Systemd-comment-ca-marche https://www.alionet.org/content.php?198-Systemd-comment-ca-marche-Partie-2 https://www.alionet.org/content.php?228-Systemd-comment-%E7a-marche-3%E9me-et-derni%E8re-partie http://www.openlogic.com/wazi/bid/351296/An-introduction-to-systemd-for-CentOS-7
Activation du service pour un lancement au boot
Vérification :
Lister les services
Liste les fichiers définissant des services :
Liste des services activés (enable) :
The state will usually be "enabled", "disabled", "static", or "masked". In this context, static means that the unit file does not contain an "install" section, which is used to enable a unit. As such, these units cannot be enabled. Usually, this means that the unit performs a one-off action or is used only as a dependency of another unit and should not be run by itself.
Source : https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units Obtenir des infos sur les services
Lister les services en échec
Relance de systemd après modification des services
Il n'est plus utilisé : cf ici
"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 »" Source : http://linuxfr.org/news/%C3%A9volutions-techniques-de-systemd |
| Dernières modifs |
|---|
| CentOS (November 1st, 2020) SystemD (October 18th, 2016) RHEL 6.4 (October 18th, 2016) RHEL 6.3 bugs et cie (October 18th, 2016) Fedora (October 18th, 2016) Firewalld (October 18th, 2016) Gestion des paquets (October 18th, 2016) |
| Contact | ||
|---|---|---|
| Pour m'envoyer un mail, Pour me laisser un commentaire :
|
