Re: Fwd: Connexion automatique sur pppoe au démarrage
Le 05/01/2019 à 19:57, Louis-Philippe a écrit : Est-ce que Network-Manager peut avoir laisser des traces dans la configuration ? Normalement, la configuration par défaut de NetworkManager dans /etc/NetworkManager/NetworkManager.conf lui dit de ne pas s'occuper des interfaces définies dans /etc/network/interfaces. --->8 [main] plugins=ifupdown,keyfile [ifupdown] managed=false --->8 Tu n'as pas créé de connexion PPPoE (DSL) dans NetworkManager ni de configuration pour l'interface ethernet support de PPPoE, n'est-ce pas ? Bien que c'est un serveur, j'ai installé un interface graphique. Je me suis aperçu que Network-manager causait des problèmes... De quel genre ?
Quelle règles pour l'édition des emails adressés à la liste Debian ?
Je fais des réponses dans le corps comme je peux. En plain text. Les messages en réponse que je vois revenir arrivent avec une présentation variable. La réponse est insérée de multiples façons. Des fois c'est très agréable, et des fois il faut retravailler les messages pour conserver un fil de discussion clair. Ça doit évidemment dépendre de mon client de messagerie (j'utilise Zimbra). Et de ma patique. Je viens de cocher la case "Reply/Forward using format of the original message". Ça pourrait améliorer au cas par cas. Quelles règles existent au sein de la liste pour que tout ça se passe bien ? Et quels outils et réglages recommandez-vous ?
Re: Sortie d'hibernation hyper longue - Stretch
suspend to ram : oui, mais ça n'est pas une hibernation. Mais au fait, combien de temps ça tient sur un portable ? Comment expliques-tu que soudainement l'hibernation ait un tel comportement ? - Original Message - From: "Eric Degenetais" To: debian-user-french@lists.debian.org Cc: "ML Debian User French" Sent: Saturday, January 5, 2019 3:07:44 PM Subject: Re: Sortie d'hibernation hyper longue - Stretch Le sam. 5 janv. 2019 14:06, < roger.tar...@free.fr > a écrit : Moi aussi, avant (avant quoi je ne sais pas). Mais depuis quelques mois, la sortie d'hibernation est subitemment devenue très longue. Comme dans le cas suivant : https://superuser.com/questions/918106/debian-extremely-slow-resume-after-hibernate Michael Schmid dit en juin 2017 dans cet article : In recent hibernation implementations, when resuming, only the minimal parts for the kernel to work are written back to memory from the swap; the rest is then loaded by the user-space applications themselves, as soon as it is needed. While this makes the system behave sluggishly at first, it nevertheless takes less total time to have it operating fluently, as pieces of memory that are not interesting for what you are currently doing must not be moved back yet. Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui aurait pu causer ça ? > On en arrive donc à la situation que je décrivais dans mon interprétation naïve : le système se retrouve donc complètement à la rue comme s'il venait de prendre une surcharge massive. Ça marche sans doute pour une petite configuration, en pratique sur mon poste de développement je préfère éteindre et rebooter par la suite. En fait de "sluggish at the beginning", le système ne s'en remet jamais. Si je veux juste une pause je fais du suspend to ram. Quoi testeer pour savoir si c'est uniquement un pb causé par FF ou si c'est aussi lié aux composants Debian installés ? J'ai cherché sur le net mais pas encore trouvé. - Original Message - From: "daniel huhardeaux" < no-s...@tootai.net > To: debian-user-french@lists.debian.org Sent: Saturday, January 5, 2019 1:20:27 PM Subject: Re: Sortie d'hibernation hyper longue - Stretch Le 05/01/2019 à 10:52, roger.tar...@free.fr a écrit : > Bonjour Bonjour > > Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la > sortie est immédiate. > FF est le coupable le plus probable. J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets, retour immédiat. > > Il faut vérifier qu'il n'a pas de complices. > > Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier pour > régler ce problème ? > Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ? > > Alternative : et pourquoi pas un navigateur plus simple et moins gourmand ? > > Merci > > > - Original Message - > From: roger tarani < roger.tar...@free.fr > > To: Liste Debian < debian-user-french@lists.debian.org > > Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET) > Subject: Sortie d'hibernation hyper longue - Stretch > > Bonjour > et meilleurs voeux à tous ! > > je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas > résolue (le pb FF est réglé). > > En résumé : > Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé. > RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation. > > La mise en veille et sortie de veille sont immédiates. > Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien > message que j'ai repris ici). > > Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai > pas mesuré mais disons 1 mn, et ensuite la machine était disponible). > La dernière sortie d'hibernation a du prendre environ le même temps que > l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu > supérieure. Il faut au total > > > Voici, ci-dessous les dernières mesures de 'w' avant et en sortie > d'hibernation : > le tload est très élevé. > > Avant mise en hibernation > > $ w > 10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag > dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash > dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses > dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash > dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new > dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w > > > En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller > le présent texte, mais acceptable) > > $ w > 16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > dev tty7 :0 26Nov18 37days 9:18m 1.66s > /usr/lib/gnome-session/gnome-session-binary > dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test > dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s
Re: Fwd: Connexion automatique sur pppoe au démarrage
Bonjour, Est-ce que Network-Manager peut avoir laisser des traces dans la configuration ? Bien que c'est un serveur, j'ai installé un interface graphique. Je me suis aperçu que Network-manager causait des problèmes... Bonne journée Le jeu. 3 janv. 2019, à 18 h 41, Pascal Hambourg a écrit : > Le 04/01/2019 à 00:25, Louis-Philippe a écrit : > > J'ai trouvé ça dans syslog... > > > > Jan 3 18:08:05 garfield pppd[846]: Plugin rp-pppoe.so loaded. > > Jan 3 18:08:05 garfield ifup[639]: Plugin rp-pppoe.so loaded. > > > > pppd et ifup charge deux fois le module en même temps ? > > Non, je suppose que c'est pppd qui a écrit ça sur sa sortie standard (ou > d'erreur) avant de se démoniser, et ça se retrouve dans la sortie d'ifup > qui a invoqué pppd. > > -- Louis-Philippe Gauthier
Re: Syntaxe de find
Le vendredi 04 janv. 2019 à 22:33:20 (+0100), Frederic Zulian a écrit : > Bonjour, > > J'ai récupéré le contenu d'un DD avec Photorec. > Cela a bien fonctionné mais je me retrouve avec 542 répertoires et quelques > milliers de fichiers. > > Comment puis-je extraire à travers l'ensemble des répertoires les fichiers > avec une extension spécifiques (ex jpeg) ? > > J'ai tenté : find . -name ".jpeg" -print mais il ne me retourne aucun > résultat. > > Une idée ? Le script présenté sur cette page ne répondrait-il pas à ton problème ? https://memo-linux.com/photorec-trier-automatiquement-la-restauration-par-types-dextensions/ -- À ses ruines, on voit combien l'édifice était beau.
Re: Linux for kids
Je pense que c'est Microsoft qui a tout compris : surtout apprendre aux enfants dès le plus jeune âge, que "informatique = Windows-Microsoft". Le danger n'est que celui-là, on verrouille le cerveau des enfants au parti unique, comme en Corée du Nord. Pas besoin d'aller en Corée du Nord pour que "informatique = Windows-Microsoft verrouille de cerveau des enfants" Bernard
Re: Sortie d'hibernation hyper longue - Stretch
Le sam. 5 janv. 2019 14:06, a écrit : > Moi aussi, avant (avant quoi je ne sais pas). > Mais depuis quelques mois, la sortie d'hibernation est subitemment devenue > très longue. > > Comme dans le cas suivant : > > https://superuser.com/questions/918106/debian-extremely-slow-resume-after-hibernate > > Michael Schmid dit en juin 2017 dans cet article : > In recent hibernation implementations, when resuming, only the minimal > parts for the kernel to work are written back to memory from the swap; the > rest is then loaded by the user-space applications themselves, as soon as > it is needed. > > While this makes the system behave sluggishly at first, it nevertheless > takes less total time to have it operating fluently, as pieces of memory > that are not interesting for what you are currently doing must not be moved > back yet. > > Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui > aurait pu causer ça ? > On en arrive donc à la situation que je décrivais dans mon interprétation naïve : le système se retrouve donc complètement à la rue comme s'il venait de prendre une surcharge massive. Ça marche sans doute pour une petite configuration, en pratique sur mon poste de développement je préfère éteindre et rebooter par la suite. En fait de "sluggish at the beginning", le système ne s'en remet jamais. Si je veux juste une pause je fais du suspend to ram. > > Quoi testeer pour savoir si c'est uniquement un pb causé par FF ou si > c'est aussi lié aux composants Debian installés ? > > J'ai cherché sur le net mais pas encore trouvé. > > - Original Message - > From: "daniel huhardeaux" > To: debian-user-french@lists.debian.org > Sent: Saturday, January 5, 2019 1:20:27 PM > Subject: Re: Sortie d'hibernation hyper longue - Stretch > > Le 05/01/2019 à 10:52, roger.tar...@free.fr a écrit : > > Bonjour > > Bonjour > > > > > Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : > la sortie est immédiate. > > FF est le coupable le plus probable. > > J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets, > retour immédiat. > > > > > Il faut vérifier qu'il n'a pas de complices. > > > > Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier > pour régler ce problème ? > > Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ? > > > > Alternative : et pourquoi pas un navigateur plus simple et moins > gourmand ? > > > > Merci > > > > > > - Original Message - > > From: roger tarani > > To: Liste Debian > > Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET) > > Subject: Sortie d'hibernation hyper longue - Stretch > > > > Bonjour > > et meilleurs voeux à tous ! > > > > je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est > pas résolue (le pb FF est réglé). > > > > En résumé : > > Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé. > > RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation. > > > > La mise en veille et sortie de veille sont immédiates. > > Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien > message que j'ai repris ici). > > > > Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je > n'ai pas mesuré mais disons 1 mn, et ensuite la machine était disponible). > > La dernière sortie d'hibernation a du prendre environ le même temps que > l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu > supérieure. Il faut au total > > > > > > Voici, ci-dessous les dernières mesures de 'w' avant et en sortie > d'hibernation : > > le tload est très élevé. > > > > Avant mise en hibernation > > > > $ w > > 10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29 > > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > > dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag > > dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash > > dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses > > dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash > > dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new > > dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w > > > > > > En sortie d'hibernation (avec toujours un peu de latence, pour > copier-coller le présent texte, mais acceptable) > > > > $ w > > 16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40 > > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > > dev tty7 :0 26Nov18 37days 9:18m 1.66s > /usr/lib/gnome-session/gnome-session-binary > > dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test > > dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client > > dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop > > dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash > > > > +18mn > > > > 16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30 > > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > > dev tty7 :0 26Nov18 37days 9:20m 1.66s > /usr/lib/gnome-session/gnome-session-binary > > dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test > > dev pts/7 tm
Re: Sortie d'hibernation hyper longue - Stretch
Moi aussi, avant (avant quoi je ne sais pas). Mais depuis quelques mois, la sortie d'hibernation est subitemment devenue très longue. Comme dans le cas suivant : https://superuser.com/questions/918106/debian-extremely-slow-resume-after-hibernate Michael Schmid dit en juin 2017 dans cet article : In recent hibernation implementations, when resuming, only the minimal parts for the kernel to work are written back to memory from the swap; the rest is then loaded by the user-space applications themselves, as soon as it is needed. While this makes the system behave sluggishly at first, it nevertheless takes less total time to have it operating fluently, as pieces of memory that are not interesting for what you are currently doing must not be moved back yet. Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui aurait pu causer ça ? Quoi testeer pour savoir si c'est uniquement un pb causé par FF ou si c'est aussi lié aux composants Debian installés ? J'ai cherché sur le net mais pas encore trouvé. - Original Message - From: "daniel huhardeaux" To: debian-user-french@lists.debian.org Sent: Saturday, January 5, 2019 1:20:27 PM Subject: Re: Sortie d'hibernation hyper longue - Stretch Le 05/01/2019 à 10:52, roger.tar...@free.fr a écrit : > Bonjour Bonjour > > Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la > sortie est immédiate. > FF est le coupable le plus probable. J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets, retour immédiat. > > Il faut vérifier qu'il n'a pas de complices. > > Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier pour > régler ce problème ? > Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ? > > Alternative : et pourquoi pas un navigateur plus simple et moins gourmand ? > > Merci > > > - Original Message - > From: roger tarani > To: Liste Debian > Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET) > Subject: Sortie d'hibernation hyper longue - Stretch > > Bonjour > et meilleurs voeux à tous ! > > je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas > résolue (le pb FF est réglé). > > En résumé : > Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé. > RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation. > > La mise en veille et sortie de veille sont immédiates. > Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien > message que j'ai repris ici). > > Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai > pas mesuré mais disons 1 mn, et ensuite la machine était disponible). > La dernière sortie d'hibernation a du prendre environ le même temps que > l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu > supérieure. Il faut au total > > > Voici, ci-dessous les dernières mesures de 'w' avant et en sortie > d'hibernation : > le tload est très élevé. > > Avant mise en hibernation > > $ w > 10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag > dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash > dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses > dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash > dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new > dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w > > > En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller > le présent texte, mais acceptable) > > $ w > 16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > dev tty7 :0 26Nov18 37days 9:18m 1.66s > /usr/lib/gnome-session/gnome-session-binary > dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test > dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client > dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop > dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash > > +18mn > > 16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30 > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT > dev tty7 :0 26Nov18 37days 9:20m 1.66s > /usr/lib/gnome-session/gnome-session-binary > dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test > dev pts/7 tmux(21173).%6 Mon02 5:55m 9.31s 9.23s mosh-client > dev pts/8 tmux(21173).%7 Mon02 2days 16:06 16:06 htop > dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash > > > Que dois-je vérifier d'autre pour trouver la cause de cette lenteur > incroyable ? > Merci. > > > PRECEDENT MESSAGE > > > Bonjour > > Le lun. 31 déc. 2018 16:19, a écrit : > > Bonjour, > > La configuration avec FF tient bien. Je n'ai plus de problème. > > Je ne refais pas un message séparé > MAIS je viens de faire un essai de mise en hibernation et de sortie. > > Waouh... > 1 mn d'écran noir > 3 mn de souris clavier muets > 6-8 mn avec un temps de réponse des fenêtres de 20+, puis 10, puis 5 s
Re: Sortie d'hibernation hyper longue - Stretch
Le 05/01/2019 à 10:52, roger.tar...@free.fr a écrit : Bonjour Bonjour Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la sortie est immédiate. FF est le coupable le plus probable. J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets, retour immédiat. Il faut vérifier qu'il n'a pas de complices. Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier pour régler ce problème ? Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ? Alternative : et pourquoi pas un navigateur plus simple et moins gourmand ? Merci - Original Message - From: roger tarani To: Liste Debian Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET) Subject: Sortie d'hibernation hyper longue - Stretch Bonjour et meilleurs voeux à tous ! je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas résolue (le pb FF est réglé). En résumé : Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé. RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation. La mise en veille et sortie de veille sont immédiates. Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien message que j'ai repris ici). Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai pas mesuré mais disons 1 mn, et ensuite la machine était disponible). La dernière sortie d'hibernation a du prendre environ le même temps que l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu supérieure. Il faut au total Voici, ci-dessous les dernières mesures de 'w' avant et en sortie d'hibernation : le tload est très élevé. Avant mise en hibernation $ w 10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller le présent texte, mais acceptable) $ w 16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev tty7 :0 26Nov18 37days 9:18m 1.66s /usr/lib/gnome-session/gnome-session-binary dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash +18mn 16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev tty7 :0 26Nov18 37days 9:20m 1.66s /usr/lib/gnome-session/gnome-session-binary dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test dev pts/7 tmux(21173).%6 Mon02 5:55m 9.31s 9.23s mosh-client dev pts/8 tmux(21173).%7 Mon02 2days 16:06 16:06 htop dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash Que dois-je vérifier d'autre pour trouver la cause de cette lenteur incroyable ? Merci. PRECEDENT MESSAGE Bonjour Le lun. 31 déc. 2018 16:19, a écrit : Bonjour, La configuration avec FF tient bien. Je n'ai plus de problème. Je ne refais pas un message séparé MAIS je viens de faire un essai de mise en hibernation et de sortie. Waouh... 1 mn d'écran noir 3 mn de souris clavier muets 6-8 mn avec un temps de réponse des fenêtres de 20+, puis 10, puis 5 s à +15 mn, j'ai retrouvé une machine réactive. La SWAP est de 8 Go pour 8 Go de RAM. RAM employée à 50% SWAP employée à 30% Éric Dégenètais a écrit : Assez naïvement, ce type de configuration m'a toujours posé question. La machine démarre et se retrouve à devoir sortir 4Go du swap pour retrouver son working set pré-hibernation. Je me demande quels mécanismes existent (c'est une vraie question, je ne suis pas ironique) pour que la machine ne soit pas dans la même panade qu'une machine sauvagement sous-dimensionnée qui croule sous le swap... J'ai un vague souvenir qu'il faudrait en SWAP 1,5 fois la RAM. C'est quoi la règle ? J'ai une JVM installée pour faire tourner quelques pgm Java. Pendant tout ce temps là, la machine ne tourne pas à plein régime pour des trucs comme des scripts dans le navigateur. htop ou System monitor, quand j'arrive à y accéder ne m'indique rien d'anormal (par rapport à mon niveau de compétence modeste) Rien d'extraordinaire, sauf load average apparemment élevé (2 coeurs) $ nproc 2 $ uptime 16:05:16 up 35 days, 4:35, 5 users, load average: 1.77, 2.31, 4.98 $ uptime 16:16:16 up 35 days, 4:46, 5 users, load average: 0.74, 0.93, 2.83 mesures sur 1/5/15 mn On voit bien qu'il y a eu la queue au portillon... mais pourquoi ? Que faut-il vérifier d'autre pour en savoir plus et corriger ça ? Merci - Original Messag
Re: Sortie d'hibernation hyper longue - Stretch
Bonjour Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la sortie est immédiate. FF est le coupable le plus probable. Il faut vérifier qu'il n'a pas de complices. Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier pour régler ce problème ? Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ? Alternative : et pourquoi pas un navigateur plus simple et moins gourmand ? Merci - Original Message - From: roger tarani To: Liste Debian Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET) Subject: Sortie d'hibernation hyper longue - Stretch Bonjour et meilleurs voeux à tous ! je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas résolue (le pb FF est réglé). En résumé : Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé. RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation. La mise en veille et sortie de veille sont immédiates. Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien message que j'ai repris ici). Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai pas mesuré mais disons 1 mn, et ensuite la machine était disponible). La dernière sortie d'hibernation a du prendre environ le même temps que l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu supérieure. Il faut au total Voici, ci-dessous les dernières mesures de 'w' avant et en sortie d'hibernation : le tload est très élevé. Avant mise en hibernation $ w 10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller le présent texte, mais acceptable) $ w 16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev tty7 :0 26Nov18 37days 9:18m 1.66s /usr/lib/gnome-session/gnome-session-binary dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash +18mn 16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT dev tty7 :0 26Nov18 37days 9:20m 1.66s /usr/lib/gnome-session/gnome-session-binary dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test dev pts/7 tmux(21173).%6 Mon02 5:55m 9.31s 9.23s mosh-client dev pts/8 tmux(21173).%7 Mon02 2days 16:06 16:06 htop dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash Que dois-je vérifier d'autre pour trouver la cause de cette lenteur incroyable ? Merci. PRECEDENT MESSAGE Bonjour Le lun. 31 déc. 2018 16:19, a écrit : Bonjour, La configuration avec FF tient bien. Je n'ai plus de problème. Je ne refais pas un message séparé MAIS je viens de faire un essai de mise en hibernation et de sortie. Waouh... 1 mn d'écran noir 3 mn de souris clavier muets 6-8 mn avec un temps de réponse des fenêtres de 20+, puis 10, puis 5 s à +15 mn, j'ai retrouvé une machine réactive. La SWAP est de 8 Go pour 8 Go de RAM. RAM employée à 50% SWAP employée à 30% Éric Dégenètais a écrit : Assez naïvement, ce type de configuration m'a toujours posé question. La machine démarre et se retrouve à devoir sortir 4Go du swap pour retrouver son working set pré-hibernation. Je me demande quels mécanismes existent (c'est une vraie question, je ne suis pas ironique) pour que la machine ne soit pas dans la même panade qu'une machine sauvagement sous-dimensionnée qui croule sous le swap... J'ai un vague souvenir qu'il faudrait en SWAP 1,5 fois la RAM. C'est quoi la règle ? J'ai une JVM installée pour faire tourner quelques pgm Java. Pendant tout ce temps là, la machine ne tourne pas à plein régime pour des trucs comme des scripts dans le navigateur. htop ou System monitor, quand j'arrive à y accéder ne m'indique rien d'anormal (par rapport à mon niveau de compétence modeste) Rien d'extraordinaire, sauf load average apparemment élevé (2 coeurs) $ nproc 2 $ uptime 16:05:16 up 35 days, 4:35, 5 users, load average: 1.77, 2.31, 4.98 $ uptime 16:16:16 up 35 days, 4:46, 5 users, load average: 0.74, 0.93, 2.83 mesures sur 1/5/15 mn On voit bien qu'il y a eu la queue au portillon... mais pourquoi ? Que faut-il vérifier d'autre pour en savoir plus et corriger ça ? Merci - Original Message - From: "Jérémy Prego" To: debian-user-french@lists.debian.org Sent: Saturday, December 29, 2018 12:14:13 PM Subject: Re: Firefox : mise à jour + blocage Le 29/12/201
Re: Aide offline libreoffice 6
Je ne peux pas te dire grand chose: sous Stretch avec la version standard Stretch (5.n), j'ai accès à l'aide hors-ligne et quand je sélectionne un mot et clique sur caractère/bordure dans le menu contextuel, mon mot entier est encadré, pas les lettres qui le constituent. Pour ton problème d'aide hors-ligne sous Backports, peut-être une installation bancale avec encore des morceaux de Stable dedans?
