Pour apache, comme pour tout deamon il est toujours plus sage de ne pas faire des handler de signaux complexe. Les signaux sont asyncrhones, lorsqu'un SIGHUP est delivre le handler de ce signal est appele, le signal SIGHUP est bloque, par contre si ce handler mets du temps a s'executer, et qu'un autre signal arrive, l'autre handler va etre execute. Nous n'aurons alors execute qu'une partie des instructions du handler du SIGCHLD.
Enormement de programme ont souffert, souffrent et souffiront de ce probleme.
Un handler d'un signal _doit_ toujours faire un instruction atomique.
C'est a dire mettre un flag, et c'est tout.
Si maintenant tu preferes vraiment la methode rotate logs autant utiliser, les daemontools avec la commande
svc -h /service/apache
plutot que l'infame methode utilisee par rotatelogs...
En parlant de apache, dans les versions 1.3.x le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
>> Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
Pourquoi donc ce n'est pas la panacee ?
Lire en utilisant un read bloquant est le moins couteux en temps proc.
Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Avant d'avoir une ligne de log qui fasse cette taille.
Si ton reader vautre, il est relance...
Ensuite un reader de log de dois jamais avoir un code tres complexe. Il est donc facile de coder quelquechose de tres stable.
Surtout avec 'getln' et 'stralloc' ...
Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
>> De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
Quid de la rotation de logs ? (cf premier message)
Quid du format du timestamp ? (cf premier message)
Et du cote du developpeur:
Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Syslog est a bannir.
Meme si entre les pipe il y a un mini parsage des donnees, c'est au programmeur d'utiliser des choses simple, dans qmail par exemple c'est juste le premier octet qui defini les actions a executer et les arguments sont les byte suivants. Meme si on perd une infime parti de temps a faire une analyse sur le flux au lieu de faire seulement un read, la securite est _grandement_ amelioree ... A comparer avec le parseur de printf() ...
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Je veux dire par cette phrase qu'il serait interessant de diposer d'un appel systeme appele, par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
[^] # Re: Et l'exemple qmail ?
Posté par forc3 . En réponse à la dépêche Exec Shield: protection contre les débordements de tampons. Évalué à 10.
Enormement de programme ont souffert, souffrent et souffiront de ce probleme.
Un handler d'un signal _doit_ toujours faire un instruction atomique.
C'est a dire mettre un flag, et c'est tout.
Si maintenant tu preferes vraiment la methode rotate logs autant utiliser, les daemontools avec la commande
svc -h /service/apache
plutot que l'infame methode utilisee par rotatelogs...
En parlant de apache, dans les versions 1.3.x le programme htpasswd fait usage de tmpnam(). D'apres son man elle n'est pas vraiment recommandee ...
>> Faire un process frère pour les logs n'est pas la panacée. Il faut mettre en place des moyens de communication entre le processus qui fait les logs et ces frères (ipc surement puisque ce sont des frères).
Pourquoi donc ce n'est pas la panacee ?
Lire en utilisant un read bloquant est le moins couteux en temps proc.
Ensuite les pipe sous linux c'est PIPE_BUF: 4096 atomiquement.
Avant d'avoir une ligne de log qui fasse cette taille.
Si ton reader vautre, il est relance...
Ensuite un reader de log de dois jamais avoir un code tres complexe. Il est donc facile de coder quelquechose de tres stable.
Surtout avec 'getln' et 'stralloc' ...
Les ipc permettent le 'privilege separation' qui _doit_ etre utilise tout le temps que c'est possible.
>> De plus ta demande d'avoir des deamons qui tourne 24h/24 peut être très facilement faite en utilisant syslog(3). Par contre c'est plus coûteux en temps.
Quid de la rotation de logs ? (cf premier message)
Quid du format du timestamp ? (cf premier message)
Et du cote du developpeur:
Quid des personnes ne sachant pas utiliser les formats ? (cf premier message)
Syslog est a bannir.
Meme si entre les pipe il y a un mini parsage des donnees, c'est au programmeur d'utiliser des choses simple, dans qmail par exemple c'est juste le premier octet qui defini les actions a executer et les arguments sont les byte suivants. Meme si on perd une infime parti de temps a faire une analyse sur le flux au lieu de faire seulement un read, la securite est _grandement_ amelioree ... A comparer avec le parseur de printf() ...
> Reclamez l'implementation d'un syscall unlink() utilisant un fd et non plus un const char * (;p)
Je veux dire par cette phrase qu'il serait interessant de diposer d'un appel systeme appele, par exemple funlink() utilisant un fd au lieu d'une chaine. Pour eviter les problemes de 'race condition' que l'on trouve avec toutes les fonctions basees sur le nom.
Je ne veux pas dire qu'il faut enlever unlink().