Après migration d'une machine de Stretch à Buster, redis-server ne démarre plus avec un message cryptique de systemd avec "status ... exit-code" qui ne renseigne pas beaucoup ... comme d'habitude avec systemd !
J'ai donc lancé redis "à la main et en root" redis-server /etc/redis/redis.conf qui m'a donné un démarrage sans erreurs et un log correct.
Les fichiers de log dans /var/log/redis ne sont pas plus bavards au sujet de ce refus de démarrage... ils ne disent même rien du tout au sujet d'une erreur quelconque, comme c'est malheureusement souvent le cas avec systemd et semblent normaux pour les démarrages manuels.
Il faut examiner le syslog pour trouver une réponse :
syslog:Oct 12 17:06:27 k2000 redis-server[5973]: >>> 'logfile /var/log/redis/redis-server.log'
syslog:Oct 12 17:06:27 k2000 redis-server[5973]: Can't open the log file: Permission denied
En regardant le répertoire "redis" dans /var/log je vois qu'il ne se présente pas bien :
drwxr-s--- 2 hplip 159 4096 oct. 12 17:06 redis
Après un petit "sudo chown redis redis" tout rentre dans l'ordre et le service redis-server se lance normalement.
Je n'ai pas réussi à trouver l'origine de cette erreur ..
- Oubli de positionner les bons droits sur le répertoire lors du passage de Stretch à Buster ? Pourtant le vieux script (dans /etc/init.d) demandait aussi un fonctionnement avec le user "redis".
- Destruction de users suivi de re-création résultant dans un changement de libellé pour cet ID ?
- ......
Question sans réponse à ce jour ...
Le lendemain, nouveau refus de démarrage, vite voir le syslog et ce fichu répertoire a changé de propriétaire !!! Je repasse le chown, et ça repart. Quel est le foutu script qui effectue ce changement de propriétaire ?
Quelques jours après, j'ai enfin trouvé ... La machine sur laquelle cela se produit dispose d'un double boot avec deux SSD différents (un boot avec Xen, l'autre avec VirtualBox), mais beaucoup de répertoires sont communs aux deux environnements :
/home, /var/lib, /var/log et d'autres.
Lors du passage de Stretch à Buster j'ai "passé" les deux mises à niveau à quelques semaines d'intervalle et, mais c'est bizarre, certains users ont du être détruits et recréés, bien sûr avec des ID différents.
Lors d'un changement de boot les répertoires de redis se trouvaient avec un ID qui n'était pas celui de redis ... et donc cela plantait en "access denied".
La seule solution que j'ai trouvée c'est de modifier les fichiers password, group et shadow pour remettre tout cela dans l'ordre.
Depuis tout baigne.