Re: Fichier binaire d'un daemon writable ssi le damon est stoppé

Bonsoir,
On 1/11/21 10:55 PM, Christian Weisgerber wrote:

La commande test(1), alias « [ », invoque l'appel système access(2),
qui retourne l'erreur ETXTBSY si le fichier exécutable est en état
d'utilisation.
 C'est à cause de la mémoire virtuelle paginée. Seulement les morceaux
nécessaires d'un fichier exécutable sont transferés en mémoire vive
lorsque c'est exigé (« on-demand paging »). Évidemment, ça finirait
mal si on surécrivait le fichier et après chargeait un autre morceau.
 C'est comme ça depuis l'introduction de la mémoire virtuelle paginée
au monde Unix, il y a environ une quarantaine d'années.

Merci beaucoup pour ta réponse Christian. Et ben... j'ai appris quelque
chose.
  Ok, manifestement ce n'est pas récent mais pour moi qui vient du monde
Linux, c'est la première fois que je rencontre ça. Par exemple sur une
Ubuntu 18.04, un noyau Linux 4.15 donc, je n'ai pas le même comportement.
Sur cette Ubuntu, j'ai un daemon Apache2 qui tourne via le binaire
/usr/sbin/apache2. Comme tu peux voir ci-dessous, je n'ai pas le même
comportement qu'avec FreeBSD :
-------------------------------------------------------------
~# whoami
root
~# b=/usr/sbin/apache2
~# namei -mox "$b"
f: /usr/sbin/apache2
  Drwxr-xr-x root root /
  drwxr-xr-x root root usr
  drwxr-xr-x root root sbin
  -rwxr-xr-x root root apache2
~# echo "import os; x = os.access('$b', os.W_OK); print(x)" | python
True
~# [ -w "$b" ] && echo WRITABLE
WRITABLE
-------------------------------------------------------------
Du coup, le comportement que j'ai décrit dans mon premier message n'est-il
pas spécifique à (Free)BSD ? Ou alors, inversement, le comportement ci-dessus
n'est-il pas spécifique à Linux ? Pourquoi les deux OS se comportent-ils
différemment sur ce point ?
--
François Lafont