Le service ne démarre pas ou ne répond pas

1. Le service tourne-t-il ?

systemctl status infrariver infrariver-ingest mariadb --no-pager
journalctl -u infrariver -n 100 --no-pager

Dans le journal	Cause	Que faire
`Access denied for user 'infrariver'`	`DB_PASSWORD` de `/etc/infrariver/server.conf` différent du mot de passe créé dans MariaDB	Corrigez `DB_PASSWORD` (il ne se génère jamais tout seul, voir Installer le paquet principal), puis `systemctl restart infrariver infrariver-ingest`.
`Can't connect to MySQL server` / `Connection refused` sur le port 3306	MariaDB arrêté, ou `DB_HOST` / `DB_PORT` faux	`systemctl status mariadb` ; démarrez-le, ou corrigez `DB_HOST` / `DB_PORT`.
`Specified key was too long` au premier démarrage	MariaDB 10.3, le flux par défaut de RHEL / Rocky 8, trop ancien	Installez MariaDB 10.5 ou plus récent : voir Prérequis système.
`Address already in use`	Un autre programme écoute déjà sur `LISTEN_ADDRESS:LISTEN_PORT`	`ss -ltnp \\| grep -E ':443\\|:8000'` pour le trouver ; libérez le port ou changez `LISTEN_PORT`.
Refus SELinux (`avc: denied`)	Paquet `infrariver-selinux` installé et un accès inhabituel bloqué	`ausearch -m avc -ts recent \\| grep infrariver` ; voir SELinux.

Au démarrage, infrariver.service complète server.conf avec les clés nouvelles d'une mise à jour, vérifie le certificat TLS, puis met le schéma de la base à jour : après une mise à jour, le premier démarrage peut prendre plus longtemps.

2. Le service répond-il localement ?

Testez depuis le serveur InfraRiver lui-même, sans passer par votre proxy :

TLS direct (installation neuve)Derrière votre reverse proxy

curl -sk -o /dev/null -w "%{http_code}\n" https://127.0.0.1/login      # 200 attendu

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/login   # 200 attendu

Adaptez l'adresse et le port à LISTEN_ADDRESS et LISTEN_PORT de server.conf.

200 en local, mais erreur dans le navigateur : le problème est entre le navigateur et InfraRiver (proxy, pare-feu, DNS). Passez à l'étape 3.
Pas de réponse en local : revenez à l'étape 1.

3. Erreurs du reverse proxy

Symptôme	Cause habituelle	Que faire
502 Bad Gateway	Le proxy ne joint pas InfraRiver : service arrêté, ou `proxy_pass` vers un autre port que `LISTEN_PORT`	Étape 1, puis alignez `proxy_pass` sur `LISTEN_ADDRESS:LISTEN_PORT`.
502, ou « upstream sent no valid HTTP response »	Double TLS : `WEB_TLS_ENABLED=true` alors que le proxy envoie du HTTP simple	Soit `WEB_TLS_ENABLED=false` (le proxy fait le TLS), soit `proxy_pass https://127.0.0.1:<port>`. Voir Accès web.
504 Gateway Time-out	Une page trop lente	Lenteurs et erreurs 504.
413 Request Entity Too Large en déposant un fichier (datastream SCAP, certificat…)	Taille maximale du proxy trop petite	Augmentez `client_max_body_size` (nginx) ou l'équivalent de votre proxy.

4. Le navigateur refuse le certificat

Par défaut, InfraRiver présente un certificat auto-signé : le navigateur affiche un avertissement. Installez un certificat signé par l'autorité de votre entreprise dans Administration → TLS Web (TLS du service web), avec ses certificats intermédiaires. Derrière un reverse proxy, c'est le certificat du proxy que voit le navigateur.

5. Impossible de se connecter

Situation	Que faire
Premier accès : mot de passe `admin` inconnu	`grep ADMIN_PASSWORD /etc/infrariver/server.conf`. Ce mot de passe ne sert qu'à la création du compte : le changer ensuite dans `server.conf` n'a aucun effet.
Un utilisateur a oublié son mot de passe local	Un autre administrateur lui donne un nouveau mot de passe : menu Utilisateurs, Modifier sur sa ligne, champ mot de passe.
Connexion par l'annuaire refusée	Dans Administration → Sources d'identité : la source est-elle Activée ? Le provisionnement automatique est-il coché (sinon, l'utilisateur doit déjà avoir un compte local) ? Le certificat de l'annuaire est-il reconnu (champ Certificat CA) ? Voir Sources d'identité.
L'utilisateur se connecte, mais ne voit presque rien	Son rôle n'a pas les permissions voulues : vérifiez le mapping groupe → rôle de la source d'identité et le rôle par défaut.

6. Des modules sont bloqués

Les modules propriétaires demandent un fichier de licence valide. L'état (valide, période de grâce, expirée, absente) est sur Administration → Licence. Après la date d'expiration, 90 jours de grâce s'appliquent, puis ces modules ne sont plus débloqués. Un dépassement du nombre d'hôtes, lui, ne bloque jamais rien. Voir Licence.