Services failed souvent, obligation de relancer le serveur, pb RAM?

Cellophile · October 13, 2022, 8:36am

Mon serveur YunoHost

Matériel: VPS acheté en ligne
Version de YunoHost: 11.0.9.15
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

Hello !
Je viens vers vous pour un problème récurrent que je n’arrive plus à gérer. Avant la migration vers ynh11, mon serveur se mettait en rad à cause de services qui s’arrêtaient, de temps en temps. Pour pallier à ça, je le faisait redémarrer tous les 3 jours par cron, ça marchait très bien.
Je pensais qu’il s’agissait d’un problème de RAM, mais je ne sais pas comment vérifier d’où viennent les erreurs et pourquoi mysql et php8.0-fpm tombaient en rade de temps en temps.

Le serveur loué a 4Go de ram, Je ne comprends pas pourquoi ça ne suffirait pas, quand certains font tourner ynh sur raspberry… A moins que je me trompe et qu’un raspberry a plus de RAM que ça ?

Depuis la migration, les pannes sont très systématiques (journalières, voire plusieurs fois par jour). Mysql, php8.0-fpm, mais aussi cron, user@1007.service et d’autres, tombent en failed au bout d’un moment. J’ai créé un script pour vérifier les services et les rallumer s’ils sont en fail, ce qui marche très bien… tant que cron fonctionne…
J’ai vu qu’un fil avait été ouvert pour user@1007 ici : Systemd service for admin user fails following migration to buster
Que quelqu’un avait aussi des problèmes de mysql en fail ici : Erreurs mysql causant des erreurs HTTP 500
Je vois que les problèmes de RAM ont l’air partagés aussi ici : Mysql service keeps stopping - #9 by wbk
J’ai essayé cette commande pour voir :

journalctl -u php8.0-fpm | tail -n 100

sept. 30 00:09:48 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
sept. 30 00:09:49 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
sept. 30 11:30:10 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
sept. 30 11:30:11 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
sept. 30 11:30:11 serveur.com systemd[1]: php8.0-fpm.service: Consumed 1min 54.150s CPU time.
-- Boot ea060d5b9a5047889856aba1543e2f00 --
sept. 30 16:19:40 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
sept. 30 16:19:40 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
sept. 30 23:30:16 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
sept. 30 23:30:17 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
sept. 30 23:30:17 serveur.com systemd[1]: php8.0-fpm.service: Consumed 1min 7.251s CPU time.
-- Boot 9e95c8351a0e45bfa90e308f0bcebe3b --
oct. 02 21:32:37 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 02 21:32:38 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 02 21:45:11 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 02 21:45:12 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 02 21:45:12 serveur.com systemd[1]: php8.0-fpm.service: Consumed 18.557s CPU time.
-- Boot bc8baf9dfbd44e0ba3b68d0a61d82c7f --
oct. 02 22:58:35 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 02 22:58:36 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 03 05:00:01 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 03 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 03 05:00:01 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 03 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Consumed 3min 29.467s CPU time.
-- Boot 60f89eee4d3345f2b94fed26f1948b7e --
oct. 03 05:00:23 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 03 05:00:24 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 03 10:00:12 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 03 10:00:13 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 03 10:00:13 serveur.com systemd[1]: php8.0-fpm.service: Consumed 5min 31.003s CPU time.
oct. 03 10:13:38 serveur.com systemd[1]: php8.0-fpm.service: Unit cannot be reloaded because it is inactive.
-- Boot d07e9acb81bb4e4d96bb88612ba26920 --
oct. 03 10:18:04 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 03 10:18:05 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 03 22:00:12 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 03 22:00:13 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 03 22:00:13 serveur.com systemd[1]: php8.0-fpm.service: Consumed 3min 15.859s CPU time.
oct. 03 23:04:37 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 03 23:04:37 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 03 23:12:42 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 03 23:12:42 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 03 23:12:42 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 03 23:12:42 serveur.com systemd[1]: php8.0-fpm.service: Consumed 4.627s CPU time.
oct. 03 23:12:42 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 03 23:12:42 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 03 23:12:45 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 03 23:12:45 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 03 23:12:45 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 03 23:12:45 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 03 23:12:45 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 04 05:00:01 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 04 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 04 05:00:01 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 04 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Consumed 1min 1.956s CPU time.
-- Boot c56dca20757b4d87adcbe2b977a39e2e --
oct. 04 05:00:23 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 04 05:00:23 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 04 10:15:15 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 04 10:15:16 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 04 10:15:16 serveur.com systemd[1]: php8.0-fpm.service: Consumed 44.944s CPU time.
oct. 04 11:07:12 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 04 11:07:12 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 04 11:09:07 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 04 11:09:07 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 04 11:09:07 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 04 11:09:07 serveur.com systemd[1]: php8.0-fpm.service: Consumed 2.888s CPU time.
oct. 04 11:12:23 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 04 11:12:23 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 10 22:00:24 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 10 22:00:25 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 10 22:00:25 serveur.com systemd[1]: php8.0-fpm.service: Consumed 49min 52.762s CPU time.
oct. 10 22:05:01 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 10 22:05:02 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 11 10:15:12 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 11 10:15:12 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 11 10:15:12 serveur.com systemd[1]: php8.0-fpm.service: Consumed 1min 14.114s CPU time.
-- Boot 01a07c08b9344c80b0737199e3329f3b --
oct. 11 10:33:09 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 11 10:33:10 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 11 22:15:13 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 11 22:15:13 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 11 22:15:13 serveur.com systemd[1]: php8.0-fpm.service: Consumed 2min 28.900s CPU time.
oct. 12 00:50:02 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 12 00:50:02 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 12 05:00:01 serveur.com systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
oct. 12 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Succeeded.
oct. 12 05:00:01 serveur.com systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
oct. 12 05:00:01 serveur.com systemd[1]: php8.0-fpm.service: Consumed 23.863s CPU time.
-- Boot 2b6b41e35d5244b8b894aa42406fbc95 --
oct. 12 05:00:22 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 12 05:00:23 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 12 12:16:42 serveur.com wp(site-wp.com)[877]: Accepted password for admin-wp from IP
oct. 12 12:18:35 serveur.com wp(site-wp.com)[883]: Accepted password for admin-wp from IP
oct. 12 22:15:11 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
oct. 12 22:15:12 serveur.com systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
oct. 12 22:15:12 serveur.com systemd[1]: php8.0-fpm.service: Consumed 2min 9.773s CPU time.
-- Boot 02451f57f0b044aa96a36f412c83f379 --
oct. 13 09:41:30 serveur.com systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
oct. 13 09:41:31 serveur.com systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
oct. 13 10:15:07 serveur.com systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.

et un second pour cron :

journalctl -u cron | tail -n 100

oct. 13 10:16:08 serveur.com systemd[1]: cron.service: Unit process 16348 (clamscan) remains running after unit stopped.
oct. 13 10:16:08 serveur.com systemd[1]: cron.service: Unit process 16354 (sh) remains running after unit stopped.
oct. 13 10:16:08 serveur.com systemd[1]: cron.service: Unit process 16355 (clamscan) remains running after unit stopped.
oct. 13 10:16:08 serveur.com systemd[1]: cron.service: Consumed 8.563s CPU time.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Scheduled restart job, restart counter is at 15.
oct. 13 10:16:09 serveur.com systemd[1]: Stopped Regular background program processing daemon.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Consumed 8.890s CPU time.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16270 (cron) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16277 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16280 (php8.0) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16320 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16321 (clamscan) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16344 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16348 (clamscan) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16354 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: cron.service: Found left-over process 16355 (clamscan) in control group while starting unit. Ignoring.
oct. 13 10:16:09 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:09 serveur.com systemd[1]: Started Regular background program processing daemon.
oct. 13 10:16:09 serveur.com cron[16669]: (CRON) INFO (pidfile fd = 3)
oct. 13 10:16:09 serveur.com cron[16669]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: A process of this unit has been killed by the OOM killer.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Failed with result 'oom-kill'.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16270 (cron) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16277 (sh) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16280 (php8.0) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16320 (sh) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16321 (clamscan) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16354 (sh) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Unit process 16355 (clamscan) remains running after unit stopped.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Consumed 13.496s CPU time.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Scheduled restart job, restart counter is at 16.
oct. 13 10:16:17 serveur.com systemd[1]: Stopped Regular background program processing daemon.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Consumed 14.153s CPU time.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16270 (cron) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16277 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16280 (php8.0) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16320 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16321 (clamscan) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16354 (sh) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: cron.service: Found left-over process 16355 (clamscan) in control group while starting unit. Ignoring.
oct. 13 10:16:17 serveur.com systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
oct. 13 10:16:17 serveur.com systemd[1]: Started Regular background program processing daemon.
oct. 13 10:16:17 serveur.com cron[16747]: (CRON) INFO (pidfile fd = 3)
oct. 13 10:16:17 serveur.com cron[16747]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
oct. 13 10:17:01 serveur.com CRON[16808]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:17:01 serveur.com CRON[16807]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:17:01 serveur.com CRON[16809]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:17:01 serveur.com CRON[16810]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
oct. 13 10:17:01 serveur.com CRON[16807]: pam_unix(cron:session): session closed for user root
oct. 13 10:17:01 serveur.com CRON[16808]: pam_unix(cron:session): session closed for user root
oct. 13 10:18:01 serveur.com CRON[16881]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:18:01 serveur.com CRON[16882]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:18:01 serveur.com CRON[16881]: pam_unix(cron:session): session closed for user root
oct. 13 10:19:01 serveur.com CRON[16988]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:19:01 serveur.com CRON[16989]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:19:01 serveur.com CRON[16988]: pam_unix(cron:session): session closed for user root
oct. 13 10:20:01 serveur.com CRON[17073]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:20:01 serveur.com CRON[17074]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:20:01 serveur.com CRON[17073]: pam_unix(cron:session): session closed for user root
oct. 13 10:21:01 serveur.com CRON[17163]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:21:01 serveur.com CRON[17164]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:21:02 serveur.com CRON[17163]: pam_unix(cron:session): session closed for user root
oct. 13 10:22:01 serveur.com CRON[17233]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:22:01 serveur.com CRON[17234]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:22:01 serveur.com CRON[17233]: pam_unix(cron:session): session closed for user root
oct. 13 10:23:01 serveur.com CRON[17301]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:23:01 serveur.com CRON[17302]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:23:01 serveur.com CRON[17301]: pam_unix(cron:session): session closed for user root
oct. 13 10:24:01 serveur.com CRON[17367]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:24:01 serveur.com CRON[17368]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:24:01 serveur.com CRON[17367]: pam_unix(cron:session): session closed for user root
oct. 13 10:25:01 serveur.com CRON[17440]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:25:01 serveur.com CRON[17439]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:25:01 serveur.com CRON[17441]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:25:01 serveur.com CRON[17442]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
oct. 13 10:25:01 serveur.com CRON[17439]: pam_unix(cron:session): session closed for user root
oct. 13 10:25:01 serveur.com CRON[17440]: pam_unix(cron:session): session closed for user root
oct. 13 10:26:01 serveur.com CRON[17509]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:26:01 serveur.com CRON[17511]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:26:01 serveur.com CRON[17509]: pam_unix(cron:session): session closed for user root
oct. 13 10:27:01 serveur.com CRON[17599]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:27:01 serveur.com CRON[17600]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:27:01 serveur.com CRON[17599]: pam_unix(cron:session): session closed for user root
oct. 13 10:28:01 serveur.com CRON[17670]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
oct. 13 10:28:01 serveur.com CRON[17671]: (root) CMD (: Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de v\303\251rification des services")
oct. 13 10:28:01 serveur.com CRON[17670]: pam_unix(cron:session): session closed for user root

Est-ce que c’est vraiment un problème de RAM ? A process of this unit has been killed by the OOM killer a l’air de vouloir dire ça…

Aleks · October 14, 2022, 2:51pm

Ça dépends surtout des apps installées

Est-ce que tu saurais lister les apps qui chez toi sont succeptibles d’être gourmandes en ressource, ou bien les apps les plus utilisées (en terme de nombre d’utilisateur ou d’intensité de l’utilisation si c’est une app ~perso)

Edit: en tout cas oui, le “OOM killer”, c’est le mécanisme qui choisi un process à tuer lorsque le système n’a plus de RAM (= out of memory = OOM). Derrière tout ça il y a un calcul un peu complexe en fonction de la RAM utilisée par chaque process, de la priorité du process, de malus/bonus, etc

Cellophile · October 15, 2022, 3:35pm

Salut @Aleks !
Merci de ta réponse
Sur ce serveur, il y un wordpress de fréquentation moyenne et un nextcloud pour un usage perso.

Le reste (netdata, grafana, roundcube, onlyoffice, une webapp) n’est que très peu utilisé.

J’ai essayé de créer un fichier swap de 2GO pour voir. Depuis, le serveur ne plante plus toutes les 12h, c’est déjà ça ! Netdata m’envoie des mails de ram quasi toute utilisée, de swap pleine, de load et kill … Que je n’avais pas avant, il ne devait pas avoir le temps de les envoyer qu’il faisait partie des failed ! donc ça confirme bien que 4GO c’est pas assez.

On verra avec le temps, Je suis surpris qu’il faille dimensionner plus grand son serveur pour des services à usage personnel, intensité moyenne. Mais bon, je dois me rendre à l’évidence

Aleks · October 15, 2022, 9:28pm

Hmoui des fois il y a aussi des apps qui sont très gourmandes en ressource pour ce qu’elles font … par exemple “Sympa”, une app de gestion de mailing liste prends de base genre 1 GB de RAM en permanence, même sans aucune liste configurée ou quoi …

Une autre explication, c’est qu’une app ait une memory leak, c-a-d un programme avec l’utilisation mêmoire qui gonfle au cours du temps jusqu’à ce qu’il n’y ai plus de RAM (mais bon, je doute un peu plus que c’est ton cas chez toi, bien que ce soit juste une intuition)

Dans ton cas je me demande si Netdata ou Onlyoffice ne serait pas une app qui utilise beaucoup de ressource même si étant plutôt “passive”. La aussi c’est plus une intuition au doigt mouillé. Est-ce que tu ne peux pas justement utiliser les graphs de Netdata pour en savoir + ? (Je ne sais pas il y a un détail d’utilisation des ressources par programme) Sinon, un autre moyen est de jeter un oeil à top depuis la ligne de commande, et de faire Ctrl+M dedans pour classer par utilisation de la mémoire

Cellophile · October 16, 2022, 10:33am

Pas sympa, sympa, finalement

Pas mal du tout cette petite commande top ! netdata consomme effectivement plus que les autres même en passif, c’est-à-dire 3.5% de RAM. Vient ensuite mysql avec environ 3%, et influxdb (?) toutes les deux secondes, avec 3.5%. Bon ça fait pas beaucoup quand même
De plus, netdata, je l’ai installé justement pour essayer de voir plus précisément d’où pouvait venir les problèmes, avant j’avais monitorix, qui tombait en rade souvent, et je le suspectait d’être à l’origine des pannes justement. Donc même si netdata consomme un peu, il n’est pas à l’origine des failed, puisqu’ils existaient avant lui, il y participe peut-être un peu.

En tout cas, depuis que j’ai mis en place la swap, je n’ai plus de problèmes, je vais voir comment ça tient dans le temps. J’y vais progressivement pour voir d’où viennent les problèmes : en plus de la swap, je relançais jusqu’à présent le serveur par cron toutes les nuits. Je vais espacer les relances, voir si l’utilisation de la mémoire gonfle avec le temps, comme ton intuition le propose. Si jamais c’est le cas, je regarderai qui est le coupable (oui avec netdata on peut voir l’utilisation des ressources par utilisateur (nextcloud, wordpress…)

On y retrouve netdata (165Mo), mysql (98Mo) et influxdb (124Mo), mais aussi wordpress (260 Mo), et nextcloud (33Mo).

Merci en tout cas de tes explications, c’est beaucoup plus clair pour moi !

jarod5001 · October 18, 2022, 10:05pm

C’est très bizarre, à part WordPress, j’ai les mêmes apps et encore plus.

admin@home ~/.l/bin> free -h
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:           3,8Gi       1,5Gi       609Mi       139Mi       1,7Gi       1,9Gi
Partition d'échange:      7,0Gi       444Mi       6,5Gi

Et

admin@home ~/.l/bin> sudo yunohost app list | grep 'name'
    name: CryptPad
    name: DockerUI
    name: Element
    name: IFM
    name: Joomla blog
    name: Joomla website 
    name: LXD Dashboard
    name: Matomo
    name: Mattermost
    name: Custom Webapp
    name: joomla3 testing site
    name: Html website
    name: Navidrome
    name: NetData
    name: Nextcloud
    name: Photoview
    name: phpMyAdmin
    name: PhpSysInfo
    name: Cusdis (redirect) 
    name: website Redirect
    name: Roundcube
    name: Scratch
    name: Slingcode
    name: Strut
    name: TrustyHash
    name: Uptime Kuma
    name: Wallabag
    name: Webmin
    name: Blog writefreely

Aleks · October 19, 2022, 10:30pm

motherofgod

Cellophile · October 20, 2022, 3:38pm

Hello,
Je ne comprends pas les deux derniers messages (désolé…)
@jarod5001, tu dis que mis à part wordpress, tu as un serveur avec pleins de services et aucun problèmes de mémoire, c’est ça ?

de mon côté, je redonne les mêmes choses que toi, à un instant T (qui n’est pas représentatif de certains pics) :

admin@home:~$ free -h
                           total      utilisé      libre      partagé   tamp/cache   disponible
Mem:                       3,7Gi       1,1Gi       1,9Gi        62Mi       756Mi       2,5Gi
Partition d''échange:      2,0Gi       748Mi       1,2Gi

Et

admin@home:~$ sudo yunohost app list | grep 'name'
    name: Grafana
    name: Mail-Liste
    name: NetData
    name: Nextcloud
    name: OnlyOffice
    name: phpMyAdmin
    name: Redirect
    name: Mails
    name: Wordpress

marc · October 29, 2022, 6:31pm

Bonjour
Je signale que j ai rencontré les memes problemes d instabilité avec Bullseye sur un raspberry2
La migration depuis l ancienne version de YUNH avait fait planter mon serveur et grillé la carte microsd
J ai donc refait un serveur avec une nouvelle Carte SD de 32 Gb, avec la derniere image ISO en 32 bits pour RaspberryPi2, et je n avais installé que Sogo, Archivist, piwigo, ldapmyadmin, soit moins d’applications que mon serveur precedent . Pourtant il plantait tous les 2 jours. J’ ai résolu le probleme en suivant ce post et en augmentant la taille du swap. Ma conclusion est qu il doit vraiment y avoir n probleme de gestion memoire dans bullseye

jarod5001 · October 29, 2022, 9:03pm

Swap sur carte sd va la tuer plus vite. Les cartes sd sont limitées par le nombre de cycles d’écriture et le swap c’est beaucoup d’écriture. Si tu peux ajouter un hdd à ta machine et déplacer le swap sur le hdd, ce sera nettement mieux.

marc · October 30, 2022, 5:02pm

merci du conseil, je vais rectifier.
En tout cas, cela signifie que le passage à bullseye est vraiment pénalisant, puisqu’il faut ajouter du matériel

Djiko · October 31, 2022, 10:26am

Hello,

je suis dans une configuration équivalente (VPS, 4GB de ram, installation pour des besoins personnels), et je rencontre depuis quelques jours le même symptôme : RAM annoncée saturée et kill de certains processus. Je soupçonne Wordpress d’être à l’origine du problème, sans pouvoir le démontrer. En dehors de la migration récente, c’est le seul véritable changement intervenu sur cette installation.

Pour confirmer, je viens de le désinstaller (il n’y avait encore rien dedans) et je vais observer ce qui se passe pendant quelques jours.

Hope this helps.

jarod5001 · November 3, 2022, 11:05pm

Quoi de neuf ?

bbateausurleau · November 24, 2022, 9:18pm

Mon serveur YunoHost

Matériel: VPS acheté en ligne
Version de YunoHost: 11.0.10.2
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Salut,
J’ai un problème du même ordre que celui ce @Cellophile
Les apps installées :
sudo yunohost app list | grep 'name'
name: CryptPad
name: Discourse
name: Etherpad
name: Garradin
name: HedgeDoc
name: JupyterLab
name: Libreto
name: Carte adh
name: NetData
name: Nextcloud
name: Opensondage
name: Roundcube
name: Vaultwarden`
Voici le lien vers le paste
Même problème des oom-kill…
Extrait :

Nov 23 12:03:08 systemd[1]: php8.0-fpm.service: Consumed 2min 43.450s CPU time.
Nov 23 17:32:55 systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
Nov 23 17:32:55 systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
Nov 23 17:36:55 systemd[1]: Stopping The PHP 8.0 FastCGI Process Manager...
Nov 23 17:36:55 systemd[1]: php8.0-fpm.service: Succeeded.
Nov 23 17:36:55 systemd[1]: Stopped The PHP 8.0 FastCGI Process Manager.
Nov 23 17:36:55 systemd[1]: php8.0-fpm.service: Consumed 6.383s CPU time.
Nov 23 17:36:55 systemd[1]: Starting The PHP 8.0 FastCGI Process Manager...
Nov 23 17:36:56 systemd[1]: Started The PHP 8.0 FastCGI Process Manager.
Nov 23 17:37:02 systemd[1]: Reloading The PHP 8.0 FastCGI Process Manager.
Nov 23 17:37:02 systemd[1]: Reloaded The PHP 8.0 FastCGI Process Manager.
Nov 23 17:37:03 php-fpm8.0[803877]: [23-Nov-2022 17:37:03] NOTICE: using inherited socket fd=8, "/var/run/php/php8.0-fpm-nextcloud.sock"
Nov 23 17:37:03 php-fpm8.0[803877]: [23-Nov-2022 17:37:03] NOTICE: using inherited socket fd=9, "/run/php/php8.0-fpm.sock"
Nov 24 07:16:30 systemd[1]: Reloading The PHP 8.0 FastCGI Process Manager.
Nov 24 07:16:30 systemd[1]: Reloaded The PHP 8.0 FastCGI Process Manager.
Nov 24 07:16:31 php-fpm8.0[803877]: [24-Nov-2022 07:16:31] NOTICE: using inherited socket fd=8, "/var/run/php/php8.0-fpm-nextcloud.sock"
Nov 24 07:16:31 php-fpm8.0[803877]: [24-Nov-2022 07:16:31] NOTICE: using inherited socket fd=9, "/run/php/php8.0-fpm.sock"
Nov 24 07:16:31 php-fpm8.0[803877]: [24-Nov-2022 07:16:31] NOTICE: using inherited socket fd=10, "/var/run/php/php8.0-fpm-garradin.sock"
Nov 24 08:24:58 systemd[1]: php8.0-fpm.service: A process of this unit has been killed by the OOM killer.
Nov 24 08:25:01 systemd[1]: php8.0-fpm.service: Failed with result 'oom-kill'.
Nov 24 08:25:01 systemd[1]: php8.0-fpm.service: Consumed 19min 47.608s CPU time.```

Que puis-je faire par rapport à ce souci ?

Cellophile · November 26, 2022, 10:37am

Bonjour @bbateausurleau ,
Dans un premier temps, tu peux voir pour installer une swap, pour voir si ça permet d’alléger la RAM, en tout cas suffisamment pour éviter d’avoir des erreurs en OOM, c’est-à-dire out of memory, comme expliqué plus haut par Aleks.
Il n’y a pas de solutions miracle pour l’instant, sinon augmenter le système, soit avec une swap, soit avec plus de ram…
Perso, j’ai aussi ajouté un bout de code dans un cron, pour relancer les services qui tombaient, pour éviter que le serveur reste en erreur trop longtemps. Mais on est d’accord que c’est pas préventif, mais curatif…

bbateausurleau · November 27, 2022, 3:26pm

Oui, j’ai fait ça, à partir de la méthodo présentée ici
Merci @Cellophile !
Pour le “bout de code dans un cron”,je serai bien intéressé à vrai dire.

Cellophile · November 30, 2022, 8:23am

Pour le bout de code, je ne suis pas plus à l’aise en bash que ça (plutôt pas d’ailleurs ), mais si ça peut dépanner…
Dans /etc/cron.d/
Faire un fichier verif_services.sh
et mettre ce code :

#!/bin/bash
exec &>>/var/log/cron.log

# fonction pour vérifier si un service est allumé.
# $1: nom du service
# $2: le service est-il actif ?
function verification {
  a="non"
  service=$1
  if [[ $2 == "active" ]]; then
     echo "$service fonctionne !";
     a="oui"
   else
    echo "$service est éteint. Relance...";
    systemctl restart $service;
  fi
  if [[ $a == "non" ]]; then
    systemctl is-active --quiet $service && ( echo "$service est relancé !" ) || ( echo "$service ne fonctionne PAS. Envoi de mail."; mail -s "$service est cassé" root <<< "Une tentative de rallumage du service $service a été effectuée par le cron verif_services.sh, mais sans succès. A vérifier manuellement." )

}


touch /tmp/verif_services /tmp/services_failed
cd /tmp

VERIF="/tmp/verif_services";
FAILED="/tmp/services_failed";

systemctl --type=service | grep failed > $VERIF

if [ -s $VERIF ]
then
        cut -d " " -f2 $VERIF > $FAILED
fi

for service in $(cat $FAILED)
do
  if [[ $service == "user@1007.service" ]]; then
    echo "user@1007.service est failed... On ne fait rien.";
  else
    ETAT=`systemctl is-active $service`
    verification $service $ETAT
  fi
done

rm $VERIF $FAILED

et un fichier verif_services

SHELL=/bin/bash
* * * * * root : Verification des services; bash /etc/cron.d/verif_services.sh || echo "echec de vérification des services"

Bon après, il m’arrive de temps en temps (pas si rarement) que le service cron lâche aussi. Et dans ce cas, le script ne se lance plus évidemment…

system · December 30, 2022, 8:23am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.