[systemd] fstab, tmpfs et tmpfiles ? (résolu)

[esclapion]

Bonjour à tous,

Quelques questions à ce sujet :

1) sur le plan philosophie, doit-il y avoir encore des montages tmpfs dans le fstab, ou vaut-il mieux les remplacer par des tmpfiles ?

2) à quel moment ces tmpfiles démarrent-ils ? J'ai par exemple eu un souci pour le fichier /var/log/ConsoleKit, mon /var/log étant en tmpfs. Je l'ai résolu en faisant un tmpfile pour le fichier /var/log/ConsoleKit.

Ne vaudrait-il pas mieux déclarer /var/log en tmpfile, et en ce cas, le problème ConsoleKit disparaîtra-t-il de façon stable ?

3) pour voir les fichiers montés par fstab, tmpfs ou non, j'utilise bêtement la commande mount. Je ne trouve pas l'équivalent pour les fichiers montés en tmpfiles, un récapitulatif de ceux-ci -> ???
Comment les démonter, par ailleurs ?

4) dans le cas d'un montage tmpfile sur un autre, comment spécifier l'ordre, de manière à éviter un montage sur un qui n'est pas encore fait ? Est-ce que le système est capable de repérer ce souci, même si ces montages sont demandés dans des fichiers de configuration différents ?

Merci d 'avance.

[tuxce]

Salut,
1. Tu confonds les tmpfiles qui correspondent à des fichiers temporaires par rapport aux programmes dans le sens où ils peuvent être effacé et les montages tmpfs qui rendent ce qui est monté temporaire de part leur caractère volatile. Ce n'est pas la même fonctionnalité.

2. Ils sont gérés avec les unités systemd-tmpfiles-*.
Pour ton souci de consolekit, tu aurais mieux fait de rajouter une condition au service consolekit-daemon.service après l'avoir copier dans /etc/systemd/system :

Code : Tout sélectionner

ConditionPathIsDirectory=/var/log/ConsoleKit

3. Vu que ce n'est pas des montages, la question ne se pose pas
Par contre, je ne sais pas s'il y a une commande pour les traquer. Le log devrait donner les éventuels échecs.

4. Pour le montage, voir 3. , pour l'ordre, c'est l'ordre alphabétique des noms des fichiers de configuration.

[esclapion]

Bonjour Tuxce,

Merci de ta réponse, j'étais bien parti dans le mur, apparemment.

Mais ce concept n'est pas facile à appréhender. Si je comprends bien, les tmpfiles.d sont des temporaires destinés à des logiciels particuliers (les démons ?). Mais si oui, pourquoi diable est-ce à l'utilisateur de le faire : le programme/paquetage concerné ne pourrait-il se les allouer/libérer lui-même ?

(edit)

Si tu as un exemple pratique, ça m'aiderait.

[tuxce]

Je vois pas bien ce que tu veux dire. Les paquets qui fournissent les unités fournissent aussi les configuration tmpfiles :

Code : Tout sélectionner

$ pacman -Qo /usr/lib/tmpfiles.d/*
/usr/lib/tmpfiles.d/apache.conf appartient à apache 2.2.22-4
/usr/lib/tmpfiles.d/console.conf appartient à systemd-tools 188-2
/usr/lib/tmpfiles.d/consolekit.conf appartient à consolekit 0.4.6-4
/usr/lib/tmpfiles.d/initscripts.conf appartient à initscripts 2012.08.2-1
/usr/lib/tmpfiles.d/legacy.conf appartient à systemd-tools 188-2
/usr/lib/tmpfiles.d/lvm2.conf appartient à lvm2 2.02.97-1
/usr/lib/tmpfiles.d/nscd.conf appartient à glibc 2.16.0-3
/usr/lib/tmpfiles.d/openssh.conf appartient à openssh 6.0p1-3
/usr/lib/tmpfiles.d/systemd.conf appartient à systemd-tools 188-2
/usr/lib/tmpfiles.d/tmp.conf appartient à systemd-tools 188-2
/usr/lib/tmpfiles.d/x11.conf appartient à systemd-tools 188-2

[esclapion]

Ce qui me gêne un peu, c'est plusieurs choses :

1) la structure du paquetage : pourquoi ces données sont-elles externes, séparées, donc accessibles par tout le monde, à la limite ? Pourquoi ces donhées ne sont-elles pas allouées par une partie init, ou allouées et protégées dans le module chargé de les gérer (découplage max) ;

2) pourquoi un mécanisme d'aussi bas niveau est-il présenté comme important pour l'utilisateur ? Ça relève de la tripaille interne, et n'est intéressant à connaître que si l'utilisateur a l'intention de développer son propre paquetage.

C'est ce qui me fait craindre d'avoir raté qqch.

[tuxce]

1) la structure du paquetage : pourquoi ces données sont-elles externes, séparées, donc accessibles par tout le monde, à la limite ?

C'est pour laisser la possibilité de configurer ! Le programme ne fixe pas en dur le chemin qu'il va utiliser.
Avant, le script de démarrage se chargeait de tester l'existence d'un répertoire / fichier (etc.) temporaire, de le créer / vider le cas échéant et d'y appliquer les bons droits. Sauf qu'il y avait autant de façons de faire que de programmes. Avec systemd, t'en as une qui est commune.

Pourquoi ces donhées ne sont-elles pas allouées par une partie init, ou allouées et protégées dans le module chargé de les gérer (découplage max) ;

désolé, mais là, j'ai rien compris

2) pourquoi un mécanisme d'aussi bas niveau est-il présenté comme important pour l'utilisateur ?

Tu suis une doc où c'est présenté comme important pour l'utilisateur final ? Ou à la limite l'écriture de certains fichiers ... Mais de toute façon, sous Arch, un utilisateur n'est jamais qu'utilisateur final

[esclapion]

Bonjour,

2. Ils sont gérés avec les unités systemd-tmpfiles-*.
Pour ton souci de consolekit, tu aurais mieux fait de rajouter une condition au service consolekit-daemon.service après l'avoir copier dans /etc/systemd/system :
ConditionPathIsDirectory=/var/log/ConsoleKit

Je viens de le faire, et ça ne semble pas marcher, du moins si je vire mon tmpfile.

Code : Tout sélectionner

[root@arch system]# pwd
/etc/systemd/system
[root@arch system]# cat console-kit-daemon.service 
[Unit]
Description=Console Manager
After=syslog.target
ConditionPathIsDirectory=/var/log/ConsoleKit

[Service]
Type=dbus
BusName=org.freedesktop.ConsoleKit
ExecStart=/usr/sbin/console-kit-daemon --no-daemon

[Install]
# We pull this in by graphical.target instead of waiting for the bus
# activation, to speed things up a little: gdm uses this anyway so it is nice
# if it is already around when gdm wants to use it and doesn't have to wait for
# it.
WantedBy=graphical.target
[root@arch system]# 

Il semble y avoir un bouclage sur la condition. Si je remets mon tmpfile, ça fonctionne.

C'est intéressant par contre pour garantir la condition, tout dépendant ensuite de comment est faite l'attente (si c'en est une).

[esclapion]

J'aurais dû le mettre dans Service, nouvel essai.

(...)

Oui, autant pour moi, désolé : là, ça passe.

Code : Tout sélectionner

[Service]
Type=dbus
BusName=org.freedesktop.ConsoleKit
ConditionPathIsDirectory=/var/log/ConsoleKit
ExecStart=/usr/sbin/console-kit-daemon --no-daemon

Merci pour cette solution. Je me demande par ailleurs comment le service attend que cette condition soit remplie.

[esclapion]

Par contre, journalctl me sort des tas d'erreurs du même genre, beaucoup également liées au montage de /var/log en tmpfs.

J'ouvre un nouveau sujet.