Systemd on Zwindler's Reflection

Emergency mode : point de montage mal ordonné par systemd-fstab-generator

Tue, 03 Jan 2017 13:00:18 +0000

Pourquoi mon OS passe en emergency lorsque je rajoute un montage bind ou automount dans la fstab ?

C’est un problème que j’ai rencontré récemment. Nous avons progressivement migré toutes nos machines sous RHEL et CentOS 7, et nous avons essuyés par mal de plâtres dans migration, notamment par manque de connaissances de la nouvelles version qui amène son lot de nouveautés comme XFS, firewalld et surtout systemd.

Un des problèmes rencontrés récemment était que sur une de nos machines, lorsqu’un reboot avait lieu, elle passait systématiquement en mode Maintenance (Emergency mode en anglais), mais que nous pouvions contourner le problème avec un simple ctrl + D.

Symptôme

En réalité, ce problème n’est apparu qu’après mise en place d’un montage de type bind ou automount sur un serveur RHEL / CentOS 7+ (ou tout autre Linux avec systemd). Il n’y a pas de messages particuliers qui indique une erreur.

Après analyse des logs, on pouvait lire les entrées suivantes dans journalctl (comme conseillé par le mode Emergency) :

journalctl -xb
[...]
-- Le chargement de l'espace utilisateur a nécessité 3905312 microsecondes.
déc. 27 02:00:18 srv01 systemd[1]: Received SIGRTMIN+20 from PID 272 (plymouthd).
déc. 27 02:00:18 srv01 systemd[1]: Received SIGRTMIN+21 from PID 272 (plymouthd).
déc. 27 13:51:22 srv01 systemd[1]: Found ordering cycle on application-share\x2dbind.mount/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on application-share.mount/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on network-online.target/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on network.target/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on NetworkManager.service/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on basic.target/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on sysinit.target/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on rhel-autorelabel-mark.service/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on local-fs.target/start
déc. 27 13:51:22 srv01 systemd[1]: Found dependency on application-share\x2dbind.mount/start
déc. 27 13:51:22 srv01 systemd[1]: Breaking ordering cycle by deleting job application-share.mount/start
déc. 27 13:51:22 srv01 systemd[1]: Job application-share.mount/start deleted to break ordering cycle starting with application-share\x2dbind.mount/start
déc. 27 13:51:22 srv01 systemd[1]: Started Commit a transient machine-id on disk.
-- Subject: L'unité (unit) systemd-machine-id-commit.service a terminé son démarrage

Dans notre cas, dans le fichier /etc/fstab, il existe 2 entrées dépendantes l’une de l’autre avec un montage samba distant et un montage de type « bind » :

vi /etc/fstab
[...]
//samba.example.org/share /application/share/ cifs _netdev,auto,users,credentials=/application/.smbcred,context=system_u:object_r:svirt_sandbox_file_t:s0 0 0
[...]
/application/share/ /application/share-bind/ none bind 0 0

Contournement

Un simple appui sur les touches Ctrl + D permet de passer outre l’erreur mais les points de montage ne sont pas disponibles à la fin de séquence de boot. Il est possible de le remonter sans problèmes particuliers avec la commande mount classique.

sudo mount -a

Cause

Le problème est très bien expliqué dans cet article en anglais (lien mort, j’utilise Internet Archive). Comme je l’annonçais en introduction, systemd a changé beaucoup de choses dans la façon dont le système traite le démarrage.

Il existe des sous fonctions de systemd, notamment systemd systemd.mount, systemd-fstab-generator et systemd.automount qui se chargent de traiter le montage des filesystems à la manière de n’importe quel autre service (appelés « units » dans la terminologie systemd).

Cependant, par défaut, il semble que le systemd-fstab-generator ne tient pas compte de l’ordre dans lesquels les filesystems sont déclarés ce qui peut provoquer des problèmes d’ordonnancement des montages !
Si c’est le cas, systemd préfère donc passer en mode Emergency et bloquer la séquence boot jusqu’à intervention d’un administrateur.

On peut confirmer le problème en allant lire les fichiers units générés par systemd-fstab-generator. C’est fichiers se trouvent dans /run/systemd/generator :

cd /run/systemd/generator/

cat application-share.mount
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=remote-fs.target
[Mount]
What=//samba.example.org/share
Where=/application/share
Type=cifs
Options=_netdev,auto,users,credentials=/application/.smbcred,context=system_u:object_r:svirt_sandbox_file_t:s0

cat application-share\\x2dbind.mount
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target
[Mount]
What=/application/share/
Where=/application/share-bind/
Type=none
Options=bind

Dans la philosophie systemd, il est nécessaire, quelque soit l’unit concerné, qu’il soit traité après ses dépendances au boot, et avant à l’extinction de la machine.

Ici, il serait nécessaire d’avoir dans les fichiers application-share.mount et application-share\x2dbind.mount la directive After= ou Require=, ce qui n’est pas le cas !

Solution

Pour résoudre le problème, il existe une directive x-systemd.requires=/path/to/dependancy à ajouter dans les options du filesystem qui doit être monter après un autre filsystem. De cette manière, le systemd-fstab-generator est capable de créer les « units systemd » disposant des bonnes directives After= et Requires=.

On doit donc modifier le fichier /etc/fstab de la façon suivante :

vi /etc/fstab
[...]
//samba.example.org/share /application/share/ cifs _netdev,x-systemd.requires=/application,auto,users,credentials=/application/.smbcred,context=system_u:object_r:svirt_sandbox_file_t:s0 0 0
[...]
/application/share/ /application/share-bind/ x-systemd.requires=/application/share bind 0 0

On peut vérifier que la commande est bien prise en compte avec la commande suivante :

systemctl show -p After application-share.mount
After=systemd-journald.socket network.target application.mount remote-fs-pre.target system.slice network-online.target -.mount

Ici on voit que /application/share nécessite que la couche réseau soit démarrée et que /application soit monté. Idem pour le montage « bind » :

systemctl show -p After application-share\\x2dbind.mount
After=application-share.mount network.target systemd-journald.socket application.mount network-online.target system.slice local-fs-pre.target remote-fs-pre.target -.mount

De même, si on lit les fichiers units générés, on retrouve bien les directives After= et Requires= attendues.

[Tutoriel] Shinken 2.4 sur CentOS/RHEL 7 – partie 3

Tue, 22 Sep 2015 16:32:00 +0000

Cet article fait parti d’une série d’articles (au moins 3) que je vais publier sur le sujet et que j’ai séparé pour les rendre un peu plus digestes. Je vous conseille quand même de ne pas en sauter pour bien comprendre de quoi on parle ;-) :

Les modules

L’ensemble des modules et en particulier le broker n’a donc aucun module d’activé. Or les interfaces graphiques sont gérées par des modules du broker pour ne citer qu’eux.

Les modules et shinken.io

Par convention (ce n’était pas forcément le cas dans les précédentes versions), la configuration des modules est définie dans des fichiers de configurations individuels qui seront stockés dans le sous dossier modules de /etc/shinken/.

On peut trouver les fichiers liés aux modules dans le répertoire /var/lib/shinken/modules/ (par défaut, mais vous pouvez le modifier dans le fichier shinken.cfg ou dans les « .ini » des démons).

cat /etc/shinken/modules/sample.cfg
# Here is a sample module that will do nothing :)
#define module{
# module_name module-sample
# module_type module-sample
# key1 value1
# key2 value2
ll /var/lib/shinken/modules
total 24
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_arbiter
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_broker_external
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_poller
drwxr-xr-x 2 shinkn shinkn 4096 17 sept. 14:34 dummy_scheduler
-rw-r--r-- 1 shinkn shinkn 919 17 sept. 14:34 __init__.py

Autant dire que pour l’instant on ne peut pas faire grand chose !

C’est un choix technique qui a été fait à partir de la version 2 (si je ne m’abuse) et qui permet de n’avoir que ce dont on a vraiment besoin, ce qui est une très bonne pratique.

Pour autant, pour éviter de trop alourdir le processus d’installation de multiples modules, l’équipe a mis au point un catalogue d’extensions qui permet d’installer les modules manquants à l’aide d’une simple ligne de commande, ce qui est très pratique.

La première fois, il faut commencer par « initialise » notre Shinken 2.4, avec la commande suivante :

shinken --init

Le site shinken.io référence à date pas moins de 138 packages dont les fameux modules qui nous manquent.

Premier module : les logs comme nagios.log

Pour installer le module de log plat à la mode « Nagios », il faut installer simple-log.

shinken install simple-log
Grabbing : simple-log
OK simple-log

Pas mal hein?

Si vous avez l’erreur suivante qui apparaît, c’est que vous n’avez pas fait la commande shinken init à l’étape précédente.

shinken install simple-log
[1442761511] ERROR: [Shnken] Cannot load cli commands, missing paths or cli entry in the config
[1442761511] ERROR: [Shnken] CLI loading not done: missing configuration data. Please run --init
shinken --init
Creating ini section paths
Creating ini section shinken.io
Saving the new configuration file /root/.shnken.ini

Installer la WebUI, l’interface graphique officielle du projet

Pour installer l’interface graphique « officielle » (aka la WebUI), il faut se rendre sur la page suivante (et la documentation qui détaille sont installation sont disponibles ici).

Toutes les dépendances python peuvent être installées via pip et le fichier requirements.txt. Pour mongodb, je vous l’ai déjà fait installer un peu plus tôt donc ça devrait déjà être fait (enfin… si vous avez suivi… sinon :-p retournez à l’article précédent).

pip install -r https://raw.githubusercontent.com/shinken-monitoring/mod-webui/develop/requirements.txt
shinken install webui2
Grabbing : webui2
OK webui2

Par défaut, le fichier de configuration webui2.cfg est créé dans le dossier /etc/shinken/modules/ et les fichiers du modules ont été déposés dans /var/lib/shinken/modules/.

Pour que notre authentification par fichier htpasswd soit prise en compte, il faut dé-commenter la ligne contenant le paramètre htpasswd_file.

[Deprecated]Vous devriez aussi changer tout de suite le paramètre auth_secret dans le fichier de configuration webui2.cfg. Remplacez CHANGEME par la valeur que vous voulez.

Historiquement il fallait changer soit même le paramètre auth_secret dans le fichier de configuration mais cette option a été remplacée par un fichier autogénéré. Cette méthode est plus sécurisante car elle évite d’oublier de le faire ;-).

htpasswd_file /etc/shinken/htpasswd.users
[...]
# Authentication secret for session cookie
#auth_secret BOBLEPONGE
# ; CHANGE THIS or someone could forge cookies
auth_secret_file /var/lib/shinken/auth_secret
[...]

Pour l’instant, seule l’authentification par Apache htpasswd est activé (vu qu’on vient de le décommenter). On pourra en rajouter d’autres par la suite mais pour faire simple, on va juste y ajouter un compte pour commencer.

htpasswd -c /etc/shinken/htpasswd.users admin

Ensuite on démarre la base mongodb

systemctl enable mongod
systemctl start mongod

Câbler le tout

On a installé deux modules, mais aucun des deux n’ont été reliés au broker : ils ne seront pas utilisés au démarrage. On modifie donc la configuration du broker en conséquence.

vi /etc/shinken/brokers/broker-master.cfg
modules simple-log,webui2

Pour plus de détails sur la configuration du broker, je vous renvoie vers la page broker de la documentation officielle.

Redémarrez l’outil pour prendre en compte la modification de configuration et connectez vous à l’URL http://@IP_shinken:7767

systemctl restart shinken

Yata !

Le dashboard. Mais pour l’instant il n’y a pas grand chose !

En cas de problèmes

Par défaut, les logs sont stockés dans le répertoire /var/log/shinken/, avec un fichier par démon.

Ils sont généralement assez détaillés et on peut moduler le niveau de détails dans les fichiers de configuration des démons que j’ai présenté un peu plus tôt.

Dans le cas où la configuration (shinken.cfg et tous les autres .cfg qui en découlent) contiendrait une erreur, l’arbiter plantera au démarrage et les informations sur son plantage seront contenues dans le fichier /tmp/bad_start_for_arbiter. Ça peut être utile.

Aller plus loin

Ça y est. Votre nouvel outil de supervision fonctionne et vous disposez d’une interface graphique pour voir ce qu’il s’y passe.

Voici quelques pistes pour réellement terminer le travail que vous venez de commencer :

D’abord vous pourriez commencer par ajouter des plugins et quelques serveurs à votre configuration pour voir comment Shinken réagit quand on lui donne un peu de travail. Et pourquoi ne pas vous économiser du travail de configuration en utilisant les packs, dans ce but ultime d’automatiser toujours plus (pour travailler moins) ?
Ensuite, vous pourriez ajouter des modules à la WebUI, comme par exemple ui-graphite ou ui-pnp pour ajouter la gestion des graphes dans votre WebUI.
Enfin, vous pourriez vous pencher sur les aspects de haute disponibilité, de répartition de charge et de gestion des royaumes, histoire de répondre à des problématiques plus complexe ?