Sur ma passerelle, j'ai un petit problème, le cron.daily ne se termine
que lorsque le prochain commence.
Par exemple, je reçois aujourd'hui le mail du cron d'hier et non pas
celui de cette nuit.
En cherchant un peu, je constate qu'en ce moment, j'ai un process qui
semble bloquer :
13159 ? S 0:00 crond
21871 ? S 0:00 \_ CROND
21916 ? S 0:00 \_ /usr/sbin/sendmail -FCronDaemon -odi -oem root
21917 ? S 0:00 \_ /usr/sbin/postdrop -r
Pourtant, quand je recevrai le mail (demain), je ne constaterai rien
d'anormal à l'intérieur.
Du coup, je ne sais pas trop vers quoi porter le reste de mes recherches,
je ne sais pas si c'est un pb dans un des scripts, et si oui lequel, ni si
c'est au niveau de postfix (auquel cas ce post serait [HS]).
Comme nous avons déjà parlé ici de nail et de wrapper sendmail, je
précise que cette machine n'est pas du tout concernée, qu'il y a un
postfix dessus qui fonctionne très bien par ailleurs.
En cherchant un peu, je constate qu'en ce moment, j'ai un process qui semble bloquer : 13159 ? S 0:00 crond 21871 ? S 0:00 _ CROND 21916 ? S 0:00 _ /usr/sbin/sendmail -FCronDaemon -odi -oem root 21917 ? S 0:00 _ /usr/sbin/postdrop -r [...]
Essaie un
strace -p 21917
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a pas des fichiers de locks qui trainent dans les spools de mail.
-- Stephane
2004-11-24, 11:03(-04), Christophe PEREZ:
[...]
En cherchant un peu, je constate qu'en ce moment, j'ai un process qui
semble bloquer :
13159 ? S 0:00 crond
21871 ? S 0:00 _ CROND
21916 ? S 0:00 _ /usr/sbin/sendmail -FCronDaemon -odi -oem root
21917 ? S 0:00 _ /usr/sbin/postdrop -r
[...]
Essaie un
strace -p 21917
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a
pas des fichiers de locks qui trainent dans les spools de mail.
En cherchant un peu, je constate qu'en ce moment, j'ai un process qui semble bloquer : 13159 ? S 0:00 crond 21871 ? S 0:00 _ CROND 21916 ? S 0:00 _ /usr/sbin/sendmail -FCronDaemon -odi -oem root 21917 ? S 0:00 _ /usr/sbin/postdrop -r [...]
Essaie un
strace -p 21917
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a pas des fichiers de locks qui trainent dans les spools de mail.
-- Stephane
Christophe PEREZ
Le Wed, 24 Nov 2004 11:03:09 -0400, Christophe PEREZ a écrit:
Du coup, je ne sais pas trop vers quoi porter le reste de mes recherches, je ne sais pas si c'est un pb dans un des scripts, et si oui lequel, ni si c'est au niveau de postfix (auquel cas ce post serait [HS]).
Je crois avoir enfin trouvé le fautif qui est le script de lancement de teamspeak. service teamspeak2-server_startscript restart m'a débloqué le cron.
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
J'ai donc : /usr/local/teamspeak-server/server.log { daily notifempty missingok prerotate service teamspeak2-server_startscript stop endscript postrotate service teamspeak2-server_startscript start endscript }
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak (/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes après disant que le lancement a échoué, même si teamspeak tourne tout à fait normalement. Peut-être est-ce à cause de cette erreur que le logrotate ne se poursuit pas et me bloque donc le cron ? J'ai mis un "exit 0" après l'appel du soft teamspeak dans le script de lancement, je verrai bien demain comme ça réagit...
Si vous avez un complément d'info à me donner sur le sujet, je reste toujours preneur. Merci.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 24 Nov 2004 11:03:09 -0400, Christophe PEREZ a écrit:
Du coup, je ne sais pas trop vers quoi porter le reste de mes recherches,
je ne sais pas si c'est un pb dans un des scripts, et si oui lequel, ni si
c'est au niveau de postfix (auquel cas ce post serait [HS]).
Je crois avoir enfin trouvé le fautif qui est le script de lancement de
teamspeak.
service teamspeak2-server_startscript restart
m'a débloqué le cron.
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la
rotation des logs, et relancer teamspeak car je ne sais pas sinon lui
faire prendre en compte le nouveau fichier de log après la "rotation".
J'ai donc :
/usr/local/teamspeak-server/server.log {
daily
notifempty
missingok
prerotate
service teamspeak2-server_startscript stop
endscript
postrotate
service teamspeak2-server_startscript start
endscript
}
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak
(/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie
systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes
après disant que le lancement a échoué, même si teamspeak tourne tout
à fait normalement.
Peut-être est-ce à cause de cette erreur que le logrotate ne se poursuit
pas et me bloque donc le cron ?
J'ai mis un "exit 0" après l'appel du soft teamspeak dans le script de
lancement, je verrai bien demain comme ça réagit...
Si vous avez un complément d'info à me donner sur le sujet, je reste
toujours preneur.
Merci.
Le Wed, 24 Nov 2004 11:03:09 -0400, Christophe PEREZ a écrit:
Du coup, je ne sais pas trop vers quoi porter le reste de mes recherches, je ne sais pas si c'est un pb dans un des scripts, et si oui lequel, ni si c'est au niveau de postfix (auquel cas ce post serait [HS]).
Je crois avoir enfin trouvé le fautif qui est le script de lancement de teamspeak. service teamspeak2-server_startscript restart m'a débloqué le cron.
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
J'ai donc : /usr/local/teamspeak-server/server.log { daily notifempty missingok prerotate service teamspeak2-server_startscript stop endscript postrotate service teamspeak2-server_startscript start endscript }
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak (/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes après disant que le lancement a échoué, même si teamspeak tourne tout à fait normalement. Peut-être est-ce à cause de cette erreur que le logrotate ne se poursuit pas et me bloque donc le cron ? J'ai mis un "exit 0" après l'appel du soft teamspeak dans le script de lancement, je verrai bien demain comme ça réagit...
Si vous avez un complément d'info à me donner sur le sujet, je reste toujours preneur. Merci.
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 24 Nov 2004 15:14:04 +0000, Stephane Chazelas a écrit:
strace -p 21917
Zut, trop tard, débloqué ;-)
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a pas des fichiers de locks qui trainent dans les spools de mail.
Ça c'est si c'était un pb postfix non ? Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon deuxième post (qui a croisé le tiens) pour ça.
Merci quand même, je note le strace.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 24 Nov 2004 15:14:04 +0000, Stephane Chazelas a écrit:
strace -p 21917
Zut, trop tard, débloqué ;-)
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a
pas des fichiers de locks qui trainent dans les spools de mail.
Ça c'est si c'était un pb postfix non ?
Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon
deuxième post (qui a croisé le tiens) pour ça.
Le Wed, 24 Nov 2004 15:14:04 +0000, Stephane Chazelas a écrit:
strace -p 21917
Zut, trop tard, débloqué ;-)
pour voir ce que fait postdrop. Regarde les logs et s'il n'y a pas des fichiers de locks qui trainent dans les spools de mail.
Ça c'est si c'était un pb postfix non ? Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon deuxième post (qui a croisé le tiens) pour ça.
Merci quand même, je note le strace.
-- Christophe PEREZ Écrivez moi sans _faute !
Stephane Chazelas
2004-11-24, 11:27(-04), Christophe PEREZ: [...]
Ça c'est si c'était un pb postfix non ? Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon deuxième post (qui a croisé le tiens) pour ça. [...]
De ton output de ps, on avait l'impression qu'il ne restait plus que postfix des prossessus impliqués dans la completion du job.
Si la commande qui joue le job est terminee mais que postfix reste, il y a des chances que ce soit postfix (ou la livraison du mail de compte-rendu de job) qui pose probleme.
-- Stephane
2004-11-24, 11:27(-04), Christophe PEREZ:
[...]
Ça c'est si c'était un pb postfix non ?
Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon
deuxième post (qui a croisé le tiens) pour ça.
[...]
De ton output de ps, on avait l'impression qu'il ne restait plus
que postfix des prossessus impliqués dans la completion du job.
Si la commande qui joue le job est terminee mais que postfix
reste, il y a des chances que ce soit postfix (ou la livraison
du mail de compte-rendu de job) qui pose probleme.
Ça c'est si c'était un pb postfix non ? Or, j'ai vraiment l'impression qu'il n'est pas du tout en cause, voir mon deuxième post (qui a croisé le tiens) pour ça. [...]
De ton output de ps, on avait l'impression qu'il ne restait plus que postfix des prossessus impliqués dans la completion du job.
Si la commande qui joue le job est terminee mais que postfix reste, il y a des chances que ce soit postfix (ou la livraison du mail de compte-rendu de job) qui pose probleme.
-- Stephane
TiChou
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
J'ai donc : /usr/local/teamspeak-server/server.log { daily notifempty missingok prerotate service teamspeak2-server_startscript stop endscript postrotate service teamspeak2-server_startscript start endscript }
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak (/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes après disant que le lancement a échoué, même si teamspeak tourne tout à fait normalement.
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de souvenir c'était lié à un problème avec le fichier pid (problème de chemin, de permissions, ...). Quand j'utilise teamspeak, je le lance avec l'option '-PID=teampspeak.pid'.
Si vous avez un complément d'info à me donner sur le sujet, je reste toujours preneur. Merci.
Avec plaisir. :)
-- TiChou
Dans le message <news:pan.2004.11.24.15.24.07.446920@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la
rotation des logs, et relancer teamspeak car je ne sais pas sinon lui
faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
J'ai donc :
/usr/local/teamspeak-server/server.log {
daily
notifempty
missingok
prerotate
service teamspeak2-server_startscript stop
endscript
postrotate
service teamspeak2-server_startscript start
endscript
}
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak
(/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie
systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes
après disant que le lancement a échoué, même si teamspeak tourne tout
à fait normalement.
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de
souvenir c'était lié à un problème avec le fichier pid (problème de chemin,
de permissions, ...). Quand j'utilise teamspeak, je le lance avec l'option
'-PID=teampspeak.pid'.
Si vous avez un complément d'info à me donner sur le sujet, je reste
toujours preneur.
Merci.
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
J'ai donc : /usr/local/teamspeak-server/server.log { daily notifempty missingok prerotate service teamspeak2-server_startscript stop endscript postrotate service teamspeak2-server_startscript start endscript }
Or, je n'ai jamais su pourquoi, mais le lancement de script de teamspeak (/usr/local/teamspeak-server/teamspeak2-server_startscript) renvoie systématiquement une erreur (je ne l'ai pas notée) plusieurs secondes après disant que le lancement a échoué, même si teamspeak tourne tout à fait normalement.
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de souvenir c'était lié à un problème avec le fichier pid (problème de chemin, de permissions, ...). Quand j'utilise teamspeak, je le lance avec l'option '-PID=teampspeak.pid'.
Si vous avez un complément d'info à me donner sur le sujet, je reste toujours preneur. Merci.
Avec plaisir. :)
-- TiChou
Christophe PEREZ
Le Wed, 24 Nov 2004 16:56:03 +0000, Stephane Chazelas a écrit:
De ton output de ps, on avait l'impression qu'il ne restait plus que postfix des prossessus impliqués dans la completion du job.
Je sais bien...
Si la commande qui joue le job est terminee mais que postfix reste, il y a des chances que ce soit postfix (ou la livraison du mail de compte-rendu de job) qui pose probleme.
Certes, et c'est bien ce que j'avais pensé la première fois que je m'en étais aperçu, mais comme le fait de faire un simple service teamspeak restart m'a tout débloqué, j'en déduis que postfix ne doit pas être responsable de beaucoup là dedans...
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 24 Nov 2004 16:56:03 +0000, Stephane Chazelas a écrit:
De ton output de ps, on avait l'impression qu'il ne restait plus
que postfix des prossessus impliqués dans la completion du job.
Je sais bien...
Si la commande qui joue le job est terminee mais que postfix
reste, il y a des chances que ce soit postfix (ou la livraison
du mail de compte-rendu de job) qui pose probleme.
Certes, et c'est bien ce que j'avais pensé la première fois que je m'en
étais aperçu, mais comme le fait de faire un simple service teamspeak
restart m'a tout débloqué, j'en déduis que postfix ne doit pas être
responsable de beaucoup là dedans...
Le Wed, 24 Nov 2004 16:56:03 +0000, Stephane Chazelas a écrit:
De ton output de ps, on avait l'impression qu'il ne restait plus que postfix des prossessus impliqués dans la completion du job.
Je sais bien...
Si la commande qui joue le job est terminee mais que postfix reste, il y a des chances que ce soit postfix (ou la livraison du mail de compte-rendu de job) qui pose probleme.
Certes, et c'est bien ce que j'avais pensé la première fois que je m'en étais aperçu, mais comme le fait de faire un simple service teamspeak restart m'a tout débloqué, j'en déduis que postfix ne doit pas être responsable de beaucoup là dedans...
-- Christophe PEREZ Écrivez moi sans _faute !
Christophe PEREZ
Le Wed, 24 Nov 2004 20:52:27 +0100, TiChou a écrit:
Utilise alors l'option 'copytruncate' de logrotate.
Ah ! j'étais donc passé à côté à l'époque, pourtant j'avais cherché, mais mal manifestement.
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de souvenir c'était lié à un problème avec le fichier pid (problème de chemin, de permissions, ...).
oui, j'avais pensé, mais mon pid est pourtant bien créé. # ls -l /usr/local/teamspeak-server/*pid -rw------- 1 teamspeak nogroup 4 nov 24 11:10 /usr/local/teamspeak-server/tsserver2.pid
Quand j'utilise teamspeak, je le lance avec l'option '-PID=teampspeak.pid'.
moi aussi, plus précisément :
su -m -c "$PRGM -pid=$PID &" $USER
avec :
CHEMIN=/usr/local/teamspeak-server cd $CHEMIN PID=$CHEMIN/tsserver2.pid PRGM=$CHEMIN/server_linux USER=teamspeak
Avec plaisir. :)
Il est pour moi ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
Le Wed, 24 Nov 2004 20:52:27 +0100, TiChou a écrit:
Utilise alors l'option 'copytruncate' de logrotate.
Ah ! j'étais donc passé à côté à l'époque, pourtant j'avais
cherché, mais mal manifestement.
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de
souvenir c'était lié à un problème avec le fichier pid (problème de chemin,
de permissions, ...).
oui, j'avais pensé, mais mon pid est pourtant bien créé.
# ls -l /usr/local/teamspeak-server/*pid
-rw------- 1 teamspeak nogroup 4 nov 24 11:10 /usr/local/teamspeak-server/tsserver2.pid
Quand j'utilise teamspeak, je le lance avec l'option
'-PID=teampspeak.pid'.
moi aussi, plus précisément :
su -m -c "$PRGM -pid=$PID &" $USER
avec :
CHEMIN=/usr/local/teamspeak-server
cd $CHEMIN
PID=$CHEMIN/tsserver2.pid
PRGM=$CHEMIN/server_linux
USER=teamspeak
J'ai, il me semble, déjà rencontré ce type de problème avec Teamspeak et de souvenir c'était lié à un problème avec le fichier pid (problème de chemin, de permissions, ...).
oui, j'avais pensé, mais mon pid est pourtant bien créé. # ls -l /usr/local/teamspeak-server/*pid -rw------- 1 teamspeak nogroup 4 nov 24 11:10 /usr/local/teamspeak-server/tsserver2.pid
Quand j'utilise teamspeak, je le lance avec l'option '-PID=teampspeak.pid'.
moi aussi, plus précisément :
su -m -c "$PRGM -pid=$PID &" $USER
avec :
CHEMIN=/usr/local/teamspeak-server cd $CHEMIN PID=$CHEMIN/tsserver2.pid PRGM=$CHEMIN/server_linux USER=teamspeak
Avec plaisir. :)
Il est pour moi ;-)
-- Christophe PEREZ Écrivez moi sans _faute !
no_spam
On Wed, 24 Nov 2004 20:52:27 +0100, TiChou wrote:
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ? Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ? Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait réduire la section critique mais pas garantir le résultat à 100 % ?
On Wed, 24 Nov 2004 20:52:27 +0100, TiChou wrote:
Dans le message <news:pan.2004.11.24.15.24.07.446920@novazur.fr>,
*Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la
rotation des logs, et relancer teamspeak car je ne sais pas sinon lui
faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Que se passe-t-il si le programme écrit des logs pendant la copie ou
entre la copie et le truncate ?
A priori, une partie de ces logs seront perdus, non ?
Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait
réduire la section critique mais pas garantir le résultat à 100 % ?
Dans le message <news:, *Christophe PEREZ* tapota sur f.c.o.l.configuration :
En effet, dans mon logrotate, je dois arrêter teamspeak, faire la rotation des logs, et relancer teamspeak car je ne sais pas sinon lui faire prendre en compte le nouveau fichier de log après la "rotation".
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ? Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ? Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait réduire la section critique mais pas garantir le résultat à 100 % ?
TiChou
Dans le message <news:, *no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate. Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut appeler un maniaque de la journalisation. Je log tout et de façon très bavarde. Cela dépend surtout aussi de la vitesse de la machine et des disques.
Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait réduire la section critique mais pas garantir le résultat à 100 % ?
Aucune idée.
-- TiChou
Dans le message <news:pan.2004.11.24.22.54.08.497005@magic.fr>,
*no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou
entre la copie et le truncate ?
A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate.
Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut
appeler un maniaque de la journalisation. Je log tout et de façon très
bavarde. Cela dépend surtout aussi de la vitesse de la machine et des
disques.
Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait
réduire la section critique mais pas garantir le résultat à 100 % ?
Dans le message <news:, *no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate. Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut appeler un maniaque de la journalisation. Je log tout et de façon très bavarde. Cela dépend surtout aussi de la vitesse de la machine et des disques.
Sauf peut-être s'il utilise une copie mappée du fichier: ça devrait réduire la section critique mais pas garantir le résultat à 100 % ?
Aucune idée.
-- TiChou
no_spam
On Thu, 25 Nov 2004 01:32:41 +0100, TiChou wrote:
Dans le message <news:, *no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate.
OK.
Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut appeler un maniaque de la journalisation. Je log tout et de façon très bavarde. Cela dépend surtout aussi de la vitesse de la machine et des disques.
Bah, je ne pense pas, c'est un peu du hasard: est-ce que le scheduler va changer de processus actif entre le copy et le truncate et le cas échéant est-ce que le process qui écrit dans le log va reprendre la main et écrire dans le log. Ca ne me semble pas très prédictible et l'incidence de la vitesse de la machine ne me semble pas claire du tout. Mais comme ça se passe dans le cache, le risque doit en effet être assez faible si la machine n'est pas trop chargée.
On Thu, 25 Nov 2004 01:32:41 +0100, TiChou wrote:
Dans le message <news:pan.2004.11.24.22.54.08.497005@magic.fr>,
*no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou
entre la copie et le truncate ?
A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate.
OK.
Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut
appeler un maniaque de la journalisation. Je log tout et de façon très
bavarde. Cela dépend surtout aussi de la vitesse de la machine et des
disques.
Bah, je ne pense pas, c'est un peu du hasard: est-ce que le scheduler va
changer de processus actif entre le copy et le truncate et le cas
échéant est-ce que le process qui écrit dans le log va reprendre la
main et écrire dans le log. Ca ne me semble pas très prédictible et
l'incidence de la vitesse de la machine ne me semble pas claire du tout.
Mais comme ça se passe dans le cache, le risque doit en effet être assez
faible si la machine n'est pas trop chargée.
Dans le message <news:, *no_spam* tapota sur f.c.o.l.configuration :
Utilise alors l'option 'copytruncate' de logrotate.
Est ce que c'est safe ?
Ça semble l'être depuis le temps que j'utilise logrotate et cette option.
Que se passe-t-il si le programme écrit des logs pendant la copie ou entre la copie et le truncate ? A priori, une partie de ces logs seront perdus, non ?
Oui, c'est un risque et c'est d'ailleurs précise dans le man de logrotate.
OK.
Mais je n'ai jamais constaté le problème. Pourtant je suis ce qu'on peut appeler un maniaque de la journalisation. Je log tout et de façon très bavarde. Cela dépend surtout aussi de la vitesse de la machine et des disques.
Bah, je ne pense pas, c'est un peu du hasard: est-ce que le scheduler va changer de processus actif entre le copy et le truncate et le cas échéant est-ce que le process qui écrit dans le log va reprendre la main et écrire dans le log. Ca ne me semble pas très prédictible et l'incidence de la vitesse de la machine ne me semble pas claire du tout. Mais comme ça se passe dans le cache, le risque doit en effet être assez faible si la machine n'est pas trop chargée.
