Bonjour
Une opération non prévue est en cours. La partie trac n'est pour le
moment plus disponible.
Vous pouvez toujours utilisez svn.
Km
Certes, mais sans trac, ou quand il ne répond qu'à moitié, on est un peu dans le noir.
Tu penses pouvoir stabiliser la situation et le rendre opérationnel à nouveau ? (ou bien une solution alternative équivalente)
Bonjour
La modification de vendredi semble fonctionner. Le serveur n'indique
pas de coupure de service depuis une soixantaine d'heures
consécutives.
Je continue à suivre l'état du serveur.
Km
Merci !
Merci azertyu pour tout le boulot que tu fais !!!
-----Message d'origine-----
Hop,
Le 16/09/2019 à 08:39, cam.lafit@azerttyu.net a écrit :
Bonjour
La modification de vendredi semble fonctionner. Le serveur n'indique
pas de coupure de service depuis une soixantaine d'heures
consécutives.
Je continue à suivre l'état du serveur.
Super, par curiosité, tu as joué sur quoi pour stabiliser le bouzin ?
++
b_b
> La modification de vendredi semble fonctionner. Le serveur n'indique
> pas de coupure de service depuis une soixantaine d'heures
> consécutives.
> Je continue à suivre l'état du serveur.
>Super, par curiosité, tu as joué sur quoi pour stabiliser le bouzin ?
Magie ?!
J'ai modifié les propriétés de WSGIDaemonProcess et augmenté la
valeur processes=6
Le problème c'est que je ne trouve aucune documentation
fiable/pertinent sur ces arguments et leur pertinence avec l'usage de
trac, donc comme tous les tests précédents c'est au doigt mouillé.
Si je résume la documentation trac, c'est Wsgi est l'approche
recommandée mais pour le reste prenez votre boule de cristal ....
L'autre approche qui fonctionnait avant chez nous c'était : prenez une
serveur musclé aux hormones boosté aux amphétamines et cela devait
passer. Les journaux remontaient les mêmes problèmes mais personne ne
le voyait.
Je suis presque sur que ça tiendra pendant un temps (1h ? 1jours ?
1semaine ?) et qu'on retombera sur les problèmes précédents.
Km