Distribution EOLE

Le choix de la solution appliquée précédemment découlé des informations dans les rapports de bugs : utiliser la contrainte de nombre maximum de fichier dans le service systemd appliquait une limite dure plutôt que douce.
L’un des développeurs indiquait qu’une correction était en cours côté squid, avec implémentation de la première partie pour la version 4.8, le reste devant venir plus tard. La version diffusée sur Ubuntu Focale est la 4.10.

L’option max_filedescriptors ne semble pas obsolète d’après la documentation : elle est même encore utilisée dans la version 7 de squid.

Elle s’utilise pour définir une limite égale ou inférieure à la limite système.

Sur Amon 2.8.1 :

# systemctl show squid.service | grep NOFILE
LimitNOFILE=524288
LimitNOFILESoft=1024

# squidclient mgr:info | grep descriptors
stub time| WARNING: BCP 177 violation. Detected non-functional IPv6 loopback.
        Maximum number of file descriptors:   65535
        Available number of file descriptors: 65522
        Reserved number of file descriptors:   100

La limite utilisée semble bien être celle déclarée dans la configuration. Est-il possible, dès lors, que le message soit apparu du fait d’une limite trop basse (et inférieure à la limite système) ?

Lorsqu’on enlève la ligne max_filedescriptors dans le fichier de configuration et qu’on redémarre le service :

squidclient mgr:info | grep descriptors
stub time| WARNING: BCP 177 violation. Detected non-functional IPv6 loopback.
        Maximum number of file descriptors:   1024
        Available number of file descriptors: 1013
        Reserved number of file descriptors:   100

On retombe bien sur la limite système (douce) visible dans les paramètres du service.