Je n’ai plus accès au serveur et le ping de ma box est nickel. Je peux toujours avoir accès à mon NAS.
Je ne rentre pas avant jeudi soir, donc nous verrons à ce moment là, puisque je ne peux rien faire d’autre pour le moment.
Est ce que ton NAS peut “voir” ton serveur ? Ping, ssh
Bonjour,
Voici le resultat demandé :
Ah, c’est très intéressant :
-“too many open files”
- on commence par vérifier le nombre de fichiers max que le système autorise :
cat /proc/sys/fs/file-max. Puis on vérifie combien de fichiers sont ouvertslsof | wc -l(ça va prendre un peu de temps)
- puis il y’a un problème avec ssh-ldap : on vérifie l’état des configurations des deux
yunohost tools regen-conf ssh --dry-run --with-diffetyunohost tools regen-conf ldap --dry-run --with-diff(et peut être même postfix et dovecot) - un problème mineur avec l’adresse wallos@. On le verra plus tard
- 9223372036854775807
- 303670
- Fait
- Erreur : No regen-conf categories named ‘ldap’
J’ai rebooté le serveur, le problème persiste.
Ah oui, je me suis trompé, essayons plus large yunohost tools regen-conf --dry-run --with-diff
As-tu redémarré ton serveur ?
-
Succès ! La configuration aurait dû être mise à jour pour la catégorie ‘dovecot’
dovecot:
applied:
/etc/dovecot/dovecot.conf:
diff: @@ -112,10 +112,6 @@
local_name xxxxxx.fr {
ssl_cert = </etc/yunohost/certs/xxxxxx.fr/crt.pem
ssl_key = </etc/yunohost/certs/xxxxxx.fr/key.pem
-}
-local_name webmin.xxxxxx.fr {- ssl_cert = </etc/yunohost/certs/webmin.xxxxxx.fr/crt.pem
- ssl_key = </etc/yunohost/certs/webmin.xxxxxx.fr/key.pem
}
curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
status: updatedpending:
-
les “xxxxxx.fr” est un autre nom de domaine que j’ai ajouté sur le nouveau serveur.
-
Je viens de relancer le serveur, le problème est toujours persistant.
-
J’ai fait un Diag après le reboot du serveur et j’ai ce message :
Pour voir les problèmes détectés, vous pouvez accéder à la section Diagnostic du webadmin ou exécuter 'yunohost diagnosis show --issues --human-readable' à partir de la ligne de commande. -
j’ai lancé la commande :
yunohost diagnosis show --issues --human-readablemais je n’ai rien qui apparait.
root@xxxxxx:~# yunohost diagnosis show --issues --human-readable
root@xxxxxx:~#
Si tu n’as pas changé la config de dovecot alors un yunohost tools regen-conf --force est nécessaire
- C’est fait :
root@xxxxxx:~# yunohost tools regen-conf --force
Succès ! La configuration a été mise à jour pour ‘dovecot’
dovecot:
applied:
/etc/dovecot/dovecot.conf:
status: updated
pending:
root@xxxxxx:~#
un petit “reboot now” : le problème est toujours présent.
Non seulement, “c’est pas donné” ; mais … le site fait peur, et pour cause !
Avant d’envoyer un disque contenant des données personnelles à Deadhardrive, quelques éléments factuels et vérifiables qui méritent réflexion. Je ne me prononce pas sur la qualité technique de la prestation (certains retours clients sont d’ailleurs positifs), mais sur la transparence de la structure.
1. Les « laboratoires » français sont des adresses de domiciliation. Le site affiche des « bureaux et laboratoires » à Paris, Lyon, Marseille, Bordeaux, Lille et Toulouse. Or :
-
L’adresse parisienne (66 av. des Champs-Élysées) est explicitement « Chez Eciffice », un centre d’affaires.
-
L’adresse lyonnaise (16 rue Cuvier, 69006) est un centre de domiciliation commerciale (Kandbaz/Digidom, à partir de ~17 €/mois), qui héberge plus de 250 sociétés « boîte aux lettres ».
-
Le site précise lui-même : « Merci de nous envoyer un email avant de passer dans nos bureaux ». Il n’y a personne sur place.
2. Aucune entité juridique française. Les mentions légales indiquent : DEADHARDRIVE LLC, enregistrée au Nouveau-Mexique (Albuquerque, USA). Pas de SIREN, pas de RCS, pas de numéro de TVA intracommunautaire — alors que les prix sont affichés « TTC ». Le seul SIRET présent sur la page est celui de l’hébergeur (o2switch), pas de l’exploitant. L’info « société enregistrée aux États-Unis » est enterrée au chapitre XII des CGV.
3. Le traitement se fait à l’étranger. D’après plusieurs avis clients détaillés, la récupération en salle blanche s’effectue dans un laboratoire à Bucarest (le labo historique était à Shanghai d’après les profils publics du fondateur). Rien de cela n’est annoncé avant l’envoi : votre disque part donc à l’étranger par transporteur, sans que ce soit dit.
4. Des CGV problématiques face à un consommateur français. Entre autres : destruction « irrémédiable » des plateaux si les 40 € de frais de retour ne sont pas payés sous 15 jours, « sans recours possible », et clause attribuant tout litige aux juridictions de Paris (clause présumée abusive pour un consommateur — art. R212-2 du Code de la consommation). Pas de médiateur de la consommation mentionné, alors que c’est obligatoire (art. L612-1). Et en pratique, un recours civil contre une LLC du Nouveau-Mexique est très difficile.
5. Retours clients contrastés. Sur Trustpilot, à côté d’avis positifs, un client rapporte en 2025 un litige financier non résolu après un an de relances, avec plainte déposée (l’entreprise conteste et invoque une facture impayée — impossible de trancher, mais ça illustre le problème du point 4 : en cas de désaccord, vous êtes seul face à une société non immatriculée en France).
Ma conclusion : la prestation existe peut-être réellement, mais confier un support contenant ses données personnelles à une structure sans existence juridique française, qui simule une présence locale et expédie les supports à l’étranger sans le dire, c’est une asymétrie de risque que je n’accepterais pas — surtout quand des laboratoires immatriculés en France, avec un vrai SIREN vérifiable sur Pappers/societe.com et des locaux réels, existent.
Réflexe avant de choisir n’importe quel prestataire de récupération : croiser l’adresse avec societe.com ou annuaire-entreprises.data.gouv.fr, vérifier le SIREN dans les mentions légales, et chercher qui d’autre est domicilié à la même adresse. Ça prend cinq minutes et ça évite bien des surprises.
(Tout ce qui précède est vérifiable publiquement : page « bureaux et laboratoires » du site, mentions légales et CGV du site, sites des domiciliataires Kandbaz/Digidom pour le 16 rue Cuvier, Trustpilot.)
1 Like
Complément d’information, après quelques vérifications supplémentaires — le tableau a de quoi faire (très) peur…
1. Le même opérateur exploite un site jumeau pour le marché suisse : s-data.ch. La page contact indique « S-DATA LLC, 12 rue le Corbusier, 1208 Genève », avec le même contact que deadhardrive.com (Sylvain Bruley, éditeur déclaré des deux sites). Et le procédé est identique : cette adresse genevoise est celle du service de domiciliation postale Swissmailbox — la prise de rendez-vous pour déposer un support passe d’ailleurs par tidycal.com/ swissmailbox/pick-up. Détail savoureux : la page « bureau de Genève » du site reconnaît elle-même qu’il s’agit d’un « bureau de dépôt à vocation logistique et non pas notre laboratoire »… tandis que le reste du site promet une récupération en salle blanche locale. Autre incohérence : « S-DATA LLC » n’existe pas en droit suisse (une société suisse serait une Sàrl, SA ou GmbH).
2. L’historique confirme que le laboratoire n’a jamais été en France. Les profils professionnels publics du fondateur (Viadeo) et la fiche Glassdoor de l’entreprise décrivent une « French company, based in Shanghai », avec mise en place de la salle blanche ISO 5… à Shanghai. Le traitement semble avoir été transféré depuis vers Bucarest (d’après plusieurs avis clients détaillés). Chronologie apparente : labo Shanghai → labo Bucarest → coquille LLC au Nouveau-Mexique → six « laboratoires » français et un « laboratoire » genevois qui sont des adresses de domiciliation.
3. Point important pour quiconque envisagerait quand même le service : le circuit de paiement suisse est moins protecteur que le français. Sur s-data.ch, le paiement est exigé par virement bancaire avant le renvoi des données. Sur deadhardrive.com, le paiement CB intervient après consultation du listing des fichiers récupérés — ce qui offre au moins un levier en cas de litige (le virement, lui, est irrévocable).
Tous ces faits sont vérifiables en quelques clics : comparer la page « bureaux et laboratoires » du site avec les pages Kandbaz/Digidom pour le 16 rue Cuvier à Lyon, et la page s-data.ch/bureau-geneve/.
Je le redis pour être équitable : plusieurs avis clients décrivent des récupérations effectivement réalisées, et je ne prétends pas que la prestation n’existe pas. Le problème est ailleurs : simuler des laboratoires locaux dans deux pays au moyen d’adresses de domiciliation, expédier les supports à l’étranger sans le dire, et opérer via une LLC américaine sans immatriculation locale, c’est priver le client de toute information loyale avant contrat — et de tout recours réaliste après. Pour des supports contenant des données personnelles, chacun jugera…
1 Like
Bonjour @jarod5001,
Après un diag, je viens de voir ce problème :
Connectivité Internet
1 problèmes
Dernière exécution : il y a 5 minutes
Le serveur ne semble pas du tout connecté à Internet ! ?
https://paste.yunohost.org/raw/ubamehugaf
Je me retrouve encore avec ce message :
reconnecting
Tentative de communication avec le serveur…
La connexion avec le serveur a été fermée pour des raisons inconnues. Peut-être que ‘yunohost-api’ ne répond plus ?
Je viens de relancer un diag et cette fois c’est bon :
https://paste.yunohost.org/raw/rakecukiji
Je ne vois pas d’ou vient le problème, car je n’ai rien fait de spécial à la nouvelle installation de Yunohost, j’ai juste fais quelques optimisations pour mon disque SSD avec l’ecriture du swap et supprimer l’IPv6.
Ne te concentre pas sur ce message.
Plutôt les autres applications que tu as sur le serveur.
Sinon, je me rappelle que netdata envoie un email s’il y’a un problème (en temps réel).
Tu peux l’essayer et voir ce que ça donne.
Bonjour @jarod5001
J’ai fais l’installation de NetData, non sans mal car je m’y suis repris en 2 fois pour l’installer à cause des coupures.
voici le 1er resultat par mail :
J’ai 3 fois ce genre de mail par la suite et un autre que voici :
si ca peut aider :
Donc, finalement, le problème est
juil. 10 14:24:15 le-geek.fr yunohost-api[147159]: Too many open files (src/epoll.cpp:65)
juil. 10 14:24:15 le-geek.fr systemd[1]: yunohost-api.service: Main process exited, code=killed, status=6/ABRT
juil. 10 14:24:15 le-geek.fr systemd[1]: yunohost-api.service: Failed with result 'signal'.
juil. 10 14:24:15 le-geek.fr systemd[1]: yunohost-api.service: Consumed 24min 34.687s CPU time.
J’ai aussi ce “Too many open files (src/epoll.cpp:65)” mais pas sur tous mes serveurs, uniquement celui qui a beaucoup d’applications.
Donc, on vérifie les processus qui ont le plus de fichiers ouverts pour comprendre mieux :
sudo lsof -n | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
Il y a probablement une des applications qui est en train de faire la synchronisation d’un grand nombre de fichiers ou qui a beaucoup d’activités réseau.
sudo lsof -n | awk ‘{print $1}’ | sort | uniq -c | sort -nr | head -n 20
272388 python3
15318 netdata
1890 mariadbd
1734 java
1704 php-fpm8.
1527 gunicorn
1215 fail2ban-
1034 nginx
972 node
792 MainThrea
548 go.d.plug
494 vaultward
360 udisksd
314 opendkim
300 nslcd
286 hbbs
284 slapd
249 dovecot
231 navidrome
222 ebpf.plug
Ah oui. Ce serait intéressant de voir les processus python en cours d’exécution : sudo lsof -c python3 | head -n 50
root@xxxxxx:\~# sudo lsof -c python3 | head -n 50
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3 633 ynh-portal cwd DIR 259,1 4096 2 /
python3 633 ynh-portal rtd DIR 259,1 4096 2 /
python3 633 ynh-portal txt REG 259,1 6834488 16010440 /usr/bin/python3.11
python3 633 ynh-portal mem REG 259,1 1693064 16121901 /usr/lib/python3/dist-packages/cryptography/hazmat/bindings/\_rust.abi3.so
python3 633 ynh-portal mem REG 259,1 39136 16018925 /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25
python3 633 ynh-portal mem REG 259,1 44032 16018927 /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25
python3 633 ynh-portal mem REG 259,1 1843792 15991397 /usr/lib/x86_64-linux-gnu/libdb-5.3.so
python3 633 ynh-portal mem REG 259,1 18656 16018924 /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25
python3 633 ynh-portal mem REG 259,1 30632 16016650 /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so.2.0.25
python3 633 ynh-portal mem REG 259,1 60008 16018923 /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25
python3 633 ynh-portal mem REG 259,1 529216 15991248 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
python3 633 ynh-portal mem REG 259,1 1792040 15992946 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
python3 633 ynh-portal mem REG 259,1 1261376 15991292 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
python3 633 ynh-portal mem REG 259,1 2209528 15993006 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.34.3
python3 633 ynh-portal mem REG 259,1 141504 16024710 /usr/lib/x86_64-linux-gnu/libnss_myhostname.so.2
python3 633 ynh-portal mem REG 259,1 43480 15991286 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.2
python3 633 ynh-portal mem REG 259,1 292856 15991275 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.6
python3 633 ynh-portal mem REG 259,1 317544 15991258 /usr/lib/x86_64-linux-gnu/libnettle.so.8.6
python3 633 ynh-portal mem REG 259,1 83968 15994506 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.3
python3 633 ynh-portal mem REG 259,1 198776 15990791 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.8
python3 633 ynh-portal mem REG 259,1 113392 16016658 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
python3 633 ynh-portal mem REG 259,1 63832 16016666 /usr/lib/x86_64-linux-gnu/liblber-2.5.so.0.1.8
python3 633 ynh-portal mem REG 259,1 380432 16016667 /usr/lib/x86_64-linux-gnu/libldap-2.5.so.0.1.8
python3 633 ynh-portal mem REG 259,1 18656 16018926 /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25
python3 633 ynh-portal mem REG 259,1 22752 16018922 /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
python3 633 ynh-portal mem REG 259,1 86912 16021040 /usr/lib/python3/dist-packages/gevent/\_gevent_c_imap.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 216968 16021047 /usr/lib/python3/dist-packages/gevent/\_gevent_cqueue.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 114048 16021044 /usr/lib/python3/dist-packages/gevent/\_gevent_cevent.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 138880 16021046 /usr/lib/python3/dist-packages/gevent/\_gevent_clocal.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 137024 16021041 /usr/lib/python3/dist-packages/gevent/\_gevent_c_semaphore.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 122144 16021035 /usr/lib/python3/dist-packages/gevent/\_gevent_c_abstract_linkable.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 256352 16021045 /usr/lib/python3/dist-packages/gevent/\_gevent_cgreenlet.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 140032 16021038 /usr/lib/python3/dist-packages/gevent/\_gevent_c_hub_primitives.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 2190440 15991846 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
python3 633 ynh-portal mem REG 259,1 77216 16023827 /usr/lib/python3/dist-packages/\_ldap.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 83424 16021043 /usr/lib/python3/dist-packages/gevent/\_gevent_c_waiter.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 69472 16021036 /usr/lib/python3/dist-packages/gevent/\_gevent_c_greenlet_primitives.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 688160 15992834 /usr/lib/x86_64-linux-gnu/libssl.so.3
python3 633 ynh-portal mem REG 259,1 4734232 15992833 /usr/lib/x86_64-linux-gnu/libcrypto.so.3
python3 633 ynh-portal mem REG 259,1 47808 16021039 /usr/lib/python3/dist-packages/gevent/\_gevent_c_ident.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 56384 16021037 /usr/lib/python3/dist-packages/gevent/\_gevent_c_hub_local.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 125312 15992975 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
python3 633 ynh-portal mem REG 259,1 103104 15993741 /usr/lib/python3/dist-packages/greenlet/\_greenlet.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 280928 16021081 /usr/lib/python3/dist-packages/gevent/libev/corecext.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 310920 16009917 /usr/lib/python3.11/lib-dynload/\_decimal.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 18656 16018921 /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25
python3 633 ynh-portal mem REG 259,1 212272 16010306 /usr/lib/python3.11/lib-dynload/\_ssl.cpython-311-x86_64-linux-gnu.so
python3 633 ynh-portal mem REG 259,1 132960 16022368 /usr/lib/x86_64-linux-gnu/libyaml-0.so.2.0.9
python3 633 ynh-portal mem REG 259,1 208472 16022383 /usr/lib/python3/dist-packages/yaml/\_yaml.cpython-311-x86_64-linux-gnu.so
J’ai aussi des mails en CRITICAL du genre :
Netdata Logo
Notification
Web log successful
label_critical.png
on le-geek.fr
32.9%
Details: Ratio of successful HTTP requests over the last minute (1xx, 2xx, 304, 401, 429)
GO TO CHART
Alert: web_log_1m_successful
Chart: web_log_nginx.requests_by_type
Raised to critical, for 0 second
On Mon Jul 13 13:13:10 CEST 2026
By: le-geek.fr
Global time: Mon Jul 13 11:13:10 UTC 2026
Classification: Workload
Role: webmaster
community_icon.png
Want to know more about this alert?
Join the troubleshooting discussion for this alert on our community forums.
configure_icon.png
Need to configure this alert?
Edit this alert's configuration file by logging into le-geek.fr and running the following command:
sudo /var/www/netdata/etc/netdata/edit-config health.d/web_log.conf
The alarm to edit is at line 58
The node has 2 warning and 0 critical additional active alert(s)
web_log_1m_redirects
Mon Jul 13 13:13:10 CEST 2026
Warning for 2 minutes
apps_group_file_descriptors_utilization
Sun Jul 12 09:01:53 CEST 2026
Warning for 1 day and 4 hours
Peux-tu nous donner la liste des applications : yunohost app list | grep "id:"
Je me suis servi d’une ia pour cette commande (je 'ai utilisé sur mon serveur)
sudo sh -c '
for pid in $(pgrep -f python); do
if [ -d /proc/$pid ]; then
cmd=$(tr "\0" " " < /proc/$pid/cmdline 2>/dev/null)
count=$(ls -1 /proc/$pid/fd 2>/dev/null | wc -l)
limit=$(grep "Max open files" /proc/$pid/limits | awk "{print \$4}")
echo "$count / $limit $pid $cmd"
fi
done' | sort -rn
Elle va afficher la liste des processus python ainsi que le nombre de fichiers ouverts par ce processus et la limite définie et la commande de ce processus.
Edit : vérifie qu’il n’y a pas de mots de passe dans la sortie de la commande avant de partager.
Et il serait intéressant de savoir comment tu as restoré ton serveur