strace pour voir les fichiers lus par une commande
12 réponses
Francois Lafont
Bonjour à tous,
Je suis sous une Ubuntu Trusty (14.04). Sous cette distribution,
je suis certain qu'en faisant :
service ssh restart
le fichier /etc/init/ssh.conf est lu à un moment donné (ce fichier
s'appelle le fichier de job upstart je crois, c'est l'équivalent
de /etc/init.d/ssh mais pour upstart).
Seulement je pensais aussi pouvoir m'assurer que le fichier
/etc/init/ssh.conf était bien lu par un des processus enfants
de la commande "service ssh restart" grâce à strace. Notamment,
avec :
LC_ALL=C strace -f -e trace=open service ssh restart
Or, je constate qu'à aucun moment strace ne m'indique que le fichier
/etc/init/ssh.conf est bien lu.
Est-ce que vous pourriez me dire pourquoi ? (sachant que je suis
absolument certain que le fichier /etc/init/ssh.conf est bien lu
suite au restart)
Ok, merci pour la méthode. Du coup dans mon cas avec Trusty, c'est /sbin/init (pid=1) apparemment qu'il faut que je strace pour avoir globalement le même genre de sortie que toi. Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus on ne voit pas la lecture du fichier "unité" correspondant à ssh. En effet, si j'ai lancé ce thread, c'est parce que je suis tombé sur un petit canular il n'y a pas très longtemps, canular que je ne peux plus reproduire hélas. Sur Trusty donc, j'ai mis à jour un package de la version N à la version N+1 (le nom du package est "ceph-osd" en l'occurrence mais on s'en moque ici je pense) et du coup le fichier /etc/init/ceph-osd.conf a été mis à jour (avec d'ailleurs de non négligeables modifications). Ensuite, j'ai voulu redémarrer le daemon ceph-osd. Et là, j'obtenais un message d'erreur dans upstart.log : - qui m'indiquait que le restart était planté avant même que le service ne soit relancé, c'était clairement au niveau de la tambouille upstart que ça merdait, - et surtout le message était absolument typique du contenu du fichier /etc/init/ceph-osd.conf dans sa version N, mais pas dans la version courante ie N+1 où justement un tel message ne pouvait plus se produire. Mon idée était alors que, pour une raison que j'ignore, le restart du daemon utilisait encore la version N du job qui n'était plus présent dans l'arborescence (car c'est la version N+1 qui était présente désormais) mais par exemple le fichier n'était pas encore supprimé du file system (pas encore "unlinked"). J'ai donc voulu valider ma « thèse » à coup de strace etc. et je n'ai jamais réussi. Au bout d'un certain temps j'ai craqué et fait un reboot et là le service a démarré sans souci (plus de message d'erreur). Ma question sur strace est partie de ce petit problème que j'ai rencontré récemment. J'ai cherché les fichiers encore utilisés par des processus mais plus présents dans l'arborescence du système avec lsof, mais je n'y ai jamais trouvé le fichier /etc/init/ceph-osd.conf dans la liste et donc je suis resté un peu dans le doute, ce qui est toujours un peu frustrant. ;) -- François Lafont
On 06/06/2016 19:22, Benoit Izac wrote:
Avec systemd, c'est systemd (pid=1) qui s'occupe de cela :
Ok, merci pour la méthode. Du coup dans mon cas avec Trusty, c'est
/sbin/init (pid=1) apparemment qu'il faut que je strace pour avoir
globalement le même genre de sortie que toi.
Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de
job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus
on ne voit pas la lecture du fichier "unité" correspondant à ssh.
En effet, si j'ai lancé ce thread, c'est parce que je suis tombé sur
un petit canular il n'y a pas très longtemps, canular que je ne peux
plus reproduire hélas. Sur Trusty donc, j'ai mis à jour un package de
la version N à la version N+1 (le nom du package est "ceph-osd" en
l'occurrence mais on s'en moque ici je pense) et du coup le fichier
/etc/init/ceph-osd.conf a été mis à jour (avec d'ailleurs de non
négligeables modifications). Ensuite, j'ai voulu redémarrer le daemon
ceph-osd. Et là, j'obtenais un message d'erreur dans upstart.log :
- qui m'indiquait que le restart était planté avant même que le service
ne soit relancé, c'était clairement au niveau de la tambouille upstart
que ça merdait,
- et surtout le message était absolument typique du contenu du fichier
/etc/init/ceph-osd.conf dans sa version N, mais pas dans la version courante
ie N+1 où justement un tel message ne pouvait plus se produire.
Mon idée était alors que, pour une raison que j'ignore, le restart du daemon
utilisait encore la version N du job qui n'était plus présent dans
l'arborescence (car c'est la version N+1 qui était présente désormais) mais
par exemple le fichier n'était pas encore supprimé du file system (pas encore
"unlinked"). J'ai donc voulu valider ma « thèse » à coup de strace etc. et
je n'ai jamais réussi. Au bout d'un certain temps j'ai craqué et fait un reboot
et là le service a démarré sans souci (plus de message d'erreur).
Ma question sur strace est partie de ce petit problème que j'ai rencontré
récemment. J'ai cherché les fichiers encore utilisés par des processus mais
plus présents dans l'arborescence du système avec lsof, mais je n'y ai
jamais trouvé le fichier /etc/init/ceph-osd.conf dans la liste et donc je
suis resté un peu dans le doute, ce qui est toujours un peu frustrant. ;)
Ok, merci pour la méthode. Du coup dans mon cas avec Trusty, c'est /sbin/init (pid=1) apparemment qu'il faut que je strace pour avoir globalement le même genre de sortie que toi. Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus on ne voit pas la lecture du fichier "unité" correspondant à ssh. En effet, si j'ai lancé ce thread, c'est parce que je suis tombé sur un petit canular il n'y a pas très longtemps, canular que je ne peux plus reproduire hélas. Sur Trusty donc, j'ai mis à jour un package de la version N à la version N+1 (le nom du package est "ceph-osd" en l'occurrence mais on s'en moque ici je pense) et du coup le fichier /etc/init/ceph-osd.conf a été mis à jour (avec d'ailleurs de non négligeables modifications). Ensuite, j'ai voulu redémarrer le daemon ceph-osd. Et là, j'obtenais un message d'erreur dans upstart.log : - qui m'indiquait que le restart était planté avant même que le service ne soit relancé, c'était clairement au niveau de la tambouille upstart que ça merdait, - et surtout le message était absolument typique du contenu du fichier /etc/init/ceph-osd.conf dans sa version N, mais pas dans la version courante ie N+1 où justement un tel message ne pouvait plus se produire. Mon idée était alors que, pour une raison que j'ignore, le restart du daemon utilisait encore la version N du job qui n'était plus présent dans l'arborescence (car c'est la version N+1 qui était présente désormais) mais par exemple le fichier n'était pas encore supprimé du file system (pas encore "unlinked"). J'ai donc voulu valider ma « thèse » à coup de strace etc. et je n'ai jamais réussi. Au bout d'un certain temps j'ai craqué et fait un reboot et là le service a démarré sans souci (plus de message d'erreur). Ma question sur strace est partie de ce petit problème que j'ai rencontré récemment. J'ai cherché les fichiers encore utilisés par des processus mais plus présents dans l'arborescence du système avec lsof, mais je n'y ai jamais trouvé le fichier /etc/init/ceph-osd.conf dans la liste et donc je suis resté un peu dans le doute, ce qui est toujours un peu frustrant. ;) -- François Lafont
Benoit Izac
Bonjour, Le 08/06/2016 à 02:07, Francois Lafont a écrit dans le message <575761da$0$5288$ :
Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus on ne voit pas la lecture du fichier "unité" correspondant à ssh.
Je ne maîtrise pas systemd (et encore moins upstart) car je n'ai jamais pris le temps de m'y intéresser mais, avec un stat(1) sur le fichier service, je m'aperçois que, malgré un restart, la date d'accès n'a pas été mise à jour. Un systemctl daemon-reexec fait lire l'ensemble des fichiers .service à systemd (le PID=1). -- Benoit Izac
Bonjour,
Le 08/06/2016 à 02:07, Francois Lafont a écrit dans le message
<575761da$0$5288$426a74cc@news.free.fr> :
Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de
job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus
on ne voit pas la lecture du fichier "unité" correspondant à ssh.
Je ne maîtrise pas systemd (et encore moins upstart) car je n'ai jamais
pris le temps de m'y intéresser mais, avec un stat(1) sur le fichier
service, je m'aperçois que, malgré un restart, la date d'accès n'a pas
été mise à jour. Un systemctl daemon-reexec fait lire l'ensemble des
fichiers .service à systemd (le PID=1).
Bonjour, Le 08/06/2016 à 02:07, Francois Lafont a écrit dans le message <575761da$0$5288$ :
Mais perso, je ne vois pas dans ma sortie l'ouverture du fichier de job upstart /etc/init/ssh.conf, de même que dans ta sortie ci-dessus on ne voit pas la lecture du fichier "unité" correspondant à ssh.
Je ne maîtrise pas systemd (et encore moins upstart) car je n'ai jamais pris le temps de m'y intéresser mais, avec un stat(1) sur le fichier service, je m'aperçois que, malgré un restart, la date d'accès n'a pas été mise à jour. Un systemctl daemon-reexec fait lire l'ensemble des fichiers .service à systemd (le PID=1). -- Benoit Izac