# Journald qui prend 23% de la RAM? **URL:** \ **Category:** Support Debian\ **Created:** [Juin 1, 2020, 12:42 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225 "2020-06-01T12:42:56Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![cyclone200](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/7ab992/32.png) [@cyclone200](https://www.debian-fr.org/u/cyclone200)\ **Post date:** [Juin 1, 2020, 12:42 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/1 "2020-06-01T12:42:56Z")
Bonjour, J’utilise VestaCP sur Debian 9. Après un petit souci de cron qui n’a pu s’exécuter à cause d’un problème de RAM, j’ai décidé d’en savoir plus. Je me suis rendu compte que sur 5Go de RAM, systemd-journal utilise 23% ! Est-ce normal ? Je vous remercie. ---
**Author:** ![kawa](https://www.debian-fr.org/user_avatar/www.debian-fr.org/kawa/32/9233_2.png) [@kawa](https://www.debian-fr.org/u/kawa)\ **Post date:** [Juin 3, 2020, 7:01 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/2 "2020-06-03T07:01:33Z")
Bonjour cyclone200, Et que donne un > `sudo journalctl` il y a peut être quelque chose à voir ?? kawa ---
**Author:** ![cyclone200](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/7ab992/32.png) [@cyclone200](https://www.debian-fr.org/u/cyclone200)\ **Post date:** [Juin 3, 2020, 9:07 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/3 "2020-06-03T09:07:19Z")
Bonjour kawa, C’est intéressant, il y a des centaines de logs qui datent de cette nuit, à 4h du matin, pour ce qu’il me semble être des tentatives de connexion : ``` -- Logs begin at Wed 2020-06-03 04:46:34 CEST, end at Wed 2020-06-03 11:02:39 CEST. -- juin 03 04:46:34 sshd[17243]: input_userauth_request: invalid user uftp [preauth] juin 03 04:46:34 sshd[17243]: pam_unix(sshd:auth): check pass; user unknown juin 03 04:46:34 sshd[17243]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:35 sshd[17240]: Failed password for root from 106.12.163.87 port 57580 ssh2 juin 03 04:46:35 sshd[17240]: Received disconnect from 106.12.163.87 port 57580:11: Bye Bye [preaut juin 03 04:46:35 sshd[17240]: Disconnected from 106.12.163.87 port 57580 [preauth] juin 03 04:46:36 sshd[17243]: Failed password for invalid user uftp from 201.163.56.82 port 46204 s juin 03 04:46:37 sshd[17243]: Received disconnect from 201.163.56.82 port 46204:11: Normal Shutdown juin 03 04:46:37 sshd[17243]: Disconnected from 201.163.56.82 port 46204 [preauth] juin 03 04:46:37 sshd[17251]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:38 sshd[17246]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:38 sshd[17253]: Invalid user odoo from 51.89.40.99 port 51594 juin 03 04:46:38 sshd[17253]: input_userauth_request: invalid user odoo [preauth] juin 03 04:46:38 sshd[17253]: pam_unix(sshd:auth): check pass; user unknown juin 03 04:46:38 sshd[17253]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:38 sshd[17249]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:40 sshd[17251]: Failed password for root from 188.166.109.87 port 34800 ssh2 juin 03 04:46:40 sshd[17251]: Received disconnect from 188.166.109.87 port 34800:11: Bye Bye [preau juin 03 04:46:40 sshd[17251]: Disconnected from 188.166.109.87 port 34800 [preauth] juin 03 04:46:40 sshd[17246]: Failed password for root from 210.123.141.241 port 40534 ssh2 juin 03 04:46:40 sshd[17253]: Failed password for invalid user odoo from 51.89.40.99 port 51594 ssh juin 03 04:46:40 sshd[17246]: Received disconnect from 210.123.141.241 port 40534:11: Bye Bye [prea juin 03 04:46:40 sshd[17246]: Disconnected from 210.123.141.241 port 40534 [preauth] juin 03 04:46:40 sshd[17253]: Received disconnect from 51.89.40.99 port 51594:11: Normal Shutdown, juin 03 04:46:40 sshd[17253]: Disconnected from 51.89.40.99 port 51594 [preauth] juin 03 04:46:40 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2 juin 03 04:46:40 sshd[17258]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:41 sshd[17256]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:42 sshd[17258]: Failed password for root from 54.37.66.73 port 49768 ssh2 juin 03 04:46:42 sshd[17258]: Received disconnect from 54.37.66.73 port 49768:11: Bye Bye [preauth] juin 03 04:46:42 sshd[17258]: Disconnected from 54.37.66.73 port 49768 [preauth] juin 03 04:46:43 sshd[17256]: Failed password for root from 210.56.23.100 port 41848 ssh2 juin 03 04:46:43 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2 juin 03 04:46:43 sshd[17256]: Received disconnect from 210.56.23.100 port 41848:11: Bye Bye [preaut juin 03 04:46:43 sshd[17256]: Disconnected from 210.56.23.100 port 41848 [preauth] juin 03 04:46:46 sshd[17249]: Failed password for root from 222.186.190.17 port 25345 ssh2 juin 03 04:46:46 sshd[17261]: Invalid user uftp from 201.163.56.82 port 34860 juin 03 04:46:46 sshd[17261]: input_userauth_request: invalid user uftp [preauth] juin 03 04:46:46 sshd[17261]: pam_unix(sshd:auth): check pass; user unknown juin 03 04:46:46 sshd[17261]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:46 sshd[17249]: Received disconnect from 222.186.190.17 port 25345:11: [preauth] juin 03 04:46:46 sshd[17249]: Disconnected from 222.186.190.17 port 25345 [preauth] juin 03 04:46:46 sshd[17249]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh rus juin 03 04:46:48 sshd[17261]: Failed password for invalid user uftp from 201.163.56.82 port 34860 s juin 03 04:46:49 sshd[17261]: Received disconnect from 201.163.56.82 port 34860:11: Normal Shutdown juin 03 04:46:49 sshd[17261]: Disconnected from 201.163.56.82 port 34860 [preauth] juin 03 04:46:52 sshd[17263]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:53 sshd[17263]: Failed password for root from 218.98.26.102 port 53236 ssh2 juin 03 04:46:54 sshd[17263]: Received disconnect from 218.98.26.102 port 53236:11: Bye Bye [preaut juin 03 04:46:54 sshd[17263]: Disconnected from 218.98.26.102 port 53236 [preauth] juin 03 04:46:57 sshd[17267]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:57 sshd[17274]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:58 sshd[17276]: Invalid user uftp from 201.163.56.82 port 51748 juin 03 04:46:58 sshd[17276]: input_userauth_request: invalid user uftp [preauth] juin 03 04:46:58 sshd[17276]: pam_unix(sshd:auth): check pass; user unknown juin 03 04:46:58 sshd[17276]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tt juin 03 04:46:59 sshd[17267]: Failed password for root from 196.203.53.20 port 55776 ssh2 juin 03 04:47:00 sshd[17274]: Failed password for root from 118.163.176.97 port 51158 ssh2 juin 03 04:47:00 sshd[17274]: Received disconnect from 118.163.176.97 port 51158:11: Bye Bye [preau juin 03 04:47:00 sshd[17274]: Disconnected from 118.163.176.97 port 51158 [preauth] ``` J’ai regardé pour les IPs, ce sont des tentatives venant de Chine, du Mexique, du Pakistan etc. Je viens de faire un `grep "Failed password" /var/log/auth.log` pour voir le nombre de tentatives similaires et il y en a des MILLIONS ; ça a presque fait crasher ma console. J’imagine que ce sont ces tentatives intempestives qui augmentent l’utilisation de la RAM. Que me conseillez-vous de faire ? Je vous remercie. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 3, 2020, 11:12 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/4 "2020-06-03T11:12:05Z")
Déjà pour voir l’occupation de la ram par journald : `ps axv | grep journald` Ensuite pour voir la configuration de journald : `cat /etc/systemd/journald.conf` et `ls -l /var/log/journal` Référence : [https://www.freedesktop.org/software/systemd/man/journald.conf.html](https://www.freedesktop.org/software/systemd/man/journald.conf.html) Avoir des centaines, voir des milliers de tentatives de connexion sur le service sshd n’a rien d’extraordinaire. Si le service est bien sécurisé (connexion uniquement par clés) il n’y rien à craindre. ---
**Author:** ![cyclone200](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/7ab992/32.png) [@cyclone200](https://www.debian-fr.org/u/cyclone200)\ **Post date:** [Juin 3, 2020, 11:25 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/5 "2020-06-03T11:25:59Z")
Bonjour Bruno et merci pour votre réponse. Voici le résultat de `ps axv | grep journald` : ``` 4680 pts/0 S+ 0:00 0 200 12575 1020 0.0 grep journald 14336 ? Ss 495:46 59625 107 1444308 1141144 19.1 /lib/systemd/systemd-journald ``` Quant à la configuration : ``` [Journal] #Storage=auto #Compress=yes #Seal=yes #SplitMode=uid #SyncIntervalSec=5m #RateLimitIntervalSec=30s #RateLimitBurst=1000 #SystemMaxUse= #SystemKeepFree= #SystemMaxFileSize= #SystemMaxFiles=100 #RuntimeMaxUse= #RuntimeKeepFree= #RuntimeMaxFileSize= #RuntimeMaxFiles=100 #MaxRetentionSec= #MaxFileSec=1month #ForwardToSyslog=yes #ForwardToKMsg=no #ForwardToConsole=no #ForwardToWall=yes #TTYPath=/dev/console #MaxLevelStore=debug #MaxLevelSyslog=debug #MaxLevelKMsg=notice #MaxLevelConsole=info #MaxLevelWall=emerg ``` Bien sûr, je comprends bien que je ne suis pas le seul à avoir des tentatives d’intrusion de ce genre ; ce qui doit être commun à tous les serveurs. Mais il est bien dommage que près de 20% de la RAM soit consacré à ce genre d’écritures. J’ai utilisé `ps -A --sort -rss -o comm,pmem,rss | head -n 20` pour obtenir le pourcentage. Je remarque d’ailleurs que fail2ban utilise 35% de la mémoire, c’est certainement lié ? Je suppose qu’avec toutes ces tentatives, fail2ban fonctionne plus. Donc entre ces deux processus, c’est déjà 55% de la RAM qui est utilisée. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 3, 2020, 11:34 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/6 "2020-06-03T11:34:30Z")
Effectivement journald occupe 19,1% de la RAM. Je n’ai jamais vu ça… Tu n’as pas donné le retour de : `ls -l /var/log/journal` Avec la configuration par défaut, si ce dossier existe, journald utilisera le disque plutôt que la RAM. Fail2ban peut utiliser énormément de RAM si les logs sont importants. ---
**Author:** ![cyclone200](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/7ab992/32.png) [@cyclone200](https://www.debian-fr.org/u/cyclone200)\ **Post date:** [Juin 3, 2020, 11:53 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/7 "2020-06-03T11:53:27Z")
Ah, en effet, je pensais que c’était l’une ou l’autre des commandes. Il me semble que ce dossier n’existe pas : `ls: impossible d'accéder à '/var/log/journal': Aucun fichier ou dossier de ce type`. J’en profite pour joindre le retour de `ps -A --sort -rss -o comm,pmem,rss | head -n 20` : ``` COMMAND %MEM RSS fail2ban-server 35.2 2104376 systemd-journal 19.0 1139904 clamd 15.6 932672 ``` ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 3, 2020, 12:01 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/8 "2020-06-03T12:01:43Z")
Le plus simple est donc de modifier le fichier /etc/systemd/journald.conf avec : ```nohighlight [Journal] Storage=persistent … ``` Puis de relancer le service : ```nohighlight systemctl restart systemd-journald ``` ceci devrait créer automatiquement le dossier /var/log/journal avec les bons droits d’accès et surtout obliger journald à utiliser le disque et non la RAM. ---
**Author:** ![cyclone200](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/c/7ab992/32.png) [@cyclone200](https://www.debian-fr.org/u/cyclone200)\ **Post date:** [Juin 4, 2020, 1:07 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/9 "2020-06-04T13:07:38Z")
Je vous remercie, cela fonctionne. L’utilisation de journald est passée de 20% à 0.9% ! Me conseillez-vous également de brider la taille du fichier avec SystemMaxFileSize ? Car j’imagine que désormais, avec autant de tentatives, le fichier pourra vite peser plusieurs gigas. ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Juin 6, 2020, 2:20 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/10 "2020-06-06T14:20:56Z")
Oui c’est sans doute une bonne chose. Mais il faudra surtout ajuster la configuration du serveur SSH et de fail2ban afin d’avoir des logs qui se remplissent un peu moins. ---
**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\ **Post date:** [Juin 6, 2020, 4:22 UTC](https://www.debian-fr.org/t/journald-qui-prend-23-de-la-ram/82225/11 "2020-06-06T16:22:03Z")
Bonjour Je pense qu’une authentification par clef ssh et sans mot de passe permettrait d’éviter d’avoir ces tentatives ratées de connexion.