log rotation, question théorique :)

"Phoenix" <Phoenix@PasDeSpamMerci.com> writes:

Immaginons que apache soit entrain d'écrire dans le fichier pile au moment
où la rotation de log à lieu ?!

En fait, sous unix, ce que compte c'est surtout le numéro d'inode qui
identifie ton fichier. Si un processus "est en train d'écrire" dans un
fichier, il a un descripteur de fichier ouvert, et il pourra continuer
à utiliser ce fichier même si il est renommé, ou même effacé (dans ce
dernier cas, l'espace disque ne sera libéré que quand tous les
processus ayant un accès à ce fichier termineront).

On peut voir ça avec la commande lsof par exemple.

Je suppose que le redémarrage d'apache est là pour forcer apache à
réouvrir le fichier, et donc à utiliser le nouveau fichier.

--
Matthieu

Phoenix wrote:

coucou :)

J'ai une qestion théorique sur le module de rotation de log...

Par défaut j'ai vu dans webmin que la configuration de log était
configurée pour faire un nouveau fichier de log tout les jours à 4h...

Avec apache par exemple, il prend le fichier apache.log et le renomme en
apache.1
La question que je me pose c'est comment c'est géré au niveau accès disque
? Immaginons que apache soit entrain d'écrire dans le fichier pile au
moment où la rotation de log à lieu ?!

Le module de rotaion de log envoi un signal HUP à apache, mais il l'envoi
*après* la rotation donc ça prévient pas un problème d'accès disque... Je
sais même pas si ça a un rapport d'ailleurs...



Enfin voilà le genre de question existanciel que je me pose :)

En simplifiant 1 peu: La +part des systèmes de fichiers sous unix (ext2,
reiserfs, etc) ne traiterons pas cela comme un pb, car le fichier n'est pas
déterminé par son nom (mais par un n° dit <<n° d'inode>>) : le fait de
supprimer un fichier ne supprime que son nom et diminue de 1 le nombre de
références au fichier. Ouvrir le fichier pour lire ou écrire compte aussi
pour une référence (grosso modo). le fait de renommer le fichier ne fait
que creer 1 nouveau nom puis supprimer l'ancien. Si le fichier n'a plus de
référence il est détruit. Donc si apache commence a écrire sur le fichier
c'est qu'il est ouvert, c'est donc qu'il a une référence. Peu importe les
changements de noms que le fichier subira tant qu'il est ouvert apache
écrira toujours dans le même fichier, même s'il s'appelle apache.1 . Quand
il sera fermé par apache le lien sera rompu. C'est le but du signal HUP qui
dit à apache de fermer le fichier de log et de le rouvrir à sa convenance
quand c'est le bon moment. Donc à partir de ce moment apache écrira dans le
nouveau fichier.

Bien sur si tu est sur un filesystem qui n'est pas du type unix... il peut
arriver des choses étranges.

Michel.

"Matthieu Moy" ...
| En fait, sous unix, ce que compte c'est surtout le numéro d'inode qui
| identifie ton fichier. Si un processus "est en train d'écrire" dans un
| fichier, il a un descripteur de fichier ouvert, et il pourra continuer
| à utiliser ce fichier même si il est renommé

haaa ok !
Bah c'est cool unix :)

| Je suppose que le redémarrage d'apache est là pour forcer apache à
| réouvrir le fichier, et donc à utiliser le nouveau fichier.

Bah oui complètement, au vu de l'explication ci-dessus ça me parait tout à
fait logique.
Et c'est même vachement bien pensé en fait :)


Merci beaucoup :)

"Michel Tatoute"...
| En simplifiant 1 peu: La +part des systèmes de fichiers sous unix (ext2,
| reiserfs, etc) ne traiterons pas cela comme un pb, car le fichier n'est
pas
| déterminé par son nom (mais par un n° dit <<n° d'inode>>) : le fait de
| supprimer un fichier ne supprime que son nom et diminue de 1 le nombre de
| références au fichier. Ouvrir le fichier pour lire ou écrire compte aussi
| pour une référence (grosso modo). le fait de renommer le fichier ne fait
| que creer 1 nouveau nom puis supprimer l'ancien. Si le fichier n'a plus de
| référence il est détruit. Donc si apache commence a écrire sur le fichier
| c'est qu'il est ouvert, c'est donc qu'il a une référence. Peu importe les
| changements de noms que le fichier subira tant qu'il est ouvert apache
| écrira toujours dans le même fichier, même s'il s'appelle apache.1 . Quand
| il sera fermé par apache le lien sera rompu. C'est le but du signal HUP
qui
| dit à apache de fermer le fichier de log et de le rouvrir à sa convenance
| quand c'est le bon moment. Donc à partir de ce moment apache écrira dans
le
| nouveau fichier.
|
| Bien sur si tu est sur un filesystem qui n'est pas du type unix... il peut
| arriver des choses étranges.



Merci beaucoup à toi aussi :)

Michel Tatoute :

Bien sur si tu est sur un filesystem qui n'est pas du type unix...

Tu penses à nfs?

Luc Habert wrote:

Michel Tatoute :

Bien sur si tu est sur un filesystem qui n'est pas du type unix...

Tu penses à nfs?

Plutot a FAT32, mais nfs aussi oui, quoi que qualifier nfs de 'non unix'
c'est osé. Non Posix?. Mais bon c'est pas un troll.... et puis peut être
que nfs de maintenant c'est plus comme dans ma jeunesse et que maintenant
ca marche...

Michel.

Michel Tatoute <tatoute@gmail.com> writes:

Plutot a FAT32, mais nfs aussi oui, quoi que qualifier nfs de 'non unix'
c'est osé. Non Posix?. Mais bon c'est pas un troll.... et puis peut être
que nfs de maintenant c'est plus comme dans ma jeunesse et que maintenant
ca marche...

A priori, NFS marche bien tant qu'il n'y a pas d'accès concurrents sur
un fichier. Mais le client n'est pas au courrant quand un autre client
renomme un fichier (c'est un choix, qui privilégie les perfs par
rapport à la cohérence des données).

--
Matthieu