Reprise du message précédent :
 
 
Oui c'est sûr que c'est agaçant en tant qu'utilisateur, mais s'il n'y a pas de volontaire pour maintenir un package, malheureusement c'est un peu la faute à personne.

Oé pour contribuer à debian faut vraiment le vouloir...
Je m'y suis remis récemment car tout le packaging python est passé sur gitlab pour une vrai coopération et ça permet enfin de bosser efficacement (le maintainer officiel c'est la team, n'importe quel membre de la team peut commiter sur le gitlab et n'importe quel mainteneur de la team peut être sollicité pour uploader)

@thana54 » tu as quelle version de Plasma / kernel ?

Le mien tourne à 110 Mo en ce moment avec du firefox (la 96beta8), du thunderbird, de la VM virtualbox avec 8 Go ... et l'ami Teams entre 800 Mo et 1 Go avec le noyau sorti ce matin (5.15.11)
Je me souviens d'une époque où le kwin libérait mal la mémoire et finissait par tout bouffer : solution = déco / reco. Je ne me souviens plus de la version.

5.23.4-1, kernel 5.15.5-1, tout à jour.
 
J'ai mis en place un zram de 1Go (utilisé actuellement à 163Mo), et je n'ai pas eu de soucis en gardant firefox + Blasphemous, c'est déjà mieux.
Je vais voir si j'ai le même comportement avec le kernel xanmod-edge 5.15.10)

bonjour, problème bizarre aujourd'hui, en prenant la main sur mon serveur de backup je me rends compte que sa date a exactement 100 ans d'avance, il indique 2121
c'est un debian en installation vraiment minimale, j'ai installé rsync dessus et c'est à peu près tout. La seule spécifité est qu'il est IPv6-only mais ça n'avait pas posé de problème jusque là.

quand je fais un 'grep timesyncd /var/log/syslog' j'ai du "Timed out waiting for reply from" toute une brouette d'IPv6. Pourtant en prenant une trace réseau et en cherchant deux ou trois de ces IP, je vois que les serveurs en question ont bien envoyé des réponses aux requêtes NTP, et que ces réponses contiennent bien la date J'ai redémarré le service pour voir bien sûr, mais ça ne change rien.

En général, j'arrête le service, je lance un ntpdate (de tête) et après je relance le service.  
Mais bon, le fait d'avoir « System clock synchronized: no », c'est pas bon signe bien souvent.

bon alors suite à une coupure de courant, l'année dans le bios était passée à 2099 (mais la date et le jour étaient bonne, curieusement). Après avoir remis le bios à la bonne année tout refonctionne, et le timesyncd se synchronise maintenant bien.
Cette dépendance de timesyncd à la date du bios ne me semble pas rassurante surtout vu les messages d'erreur peu clairs, mais bon

Pourtant ton RTC time était à 2021 donc la date de ton bios était censée être synchro avec la date de linux (donc 2121, pas 2099)
 
Ceci dit la panne de courant, ça me parait une raison assez probable.
Après coupure, avec une pile de CM faiblarde, le RTC qui part gentiment en vrille, et au démarrage suivant l'année est corrompue.

le timesyncd fourni de base est daubé.. merci systemd
solution :

et eventuellement

 
chrony étant reconnu comme mecanisme de synchro de l'heure, une fois qu"il est installé et actif, timedatectl indiquera bien la synchro

Y a-t-il une meilleur pratique pour assurer la continuité de service de Nginx+php-fpm à chaque mise à jour?
 
À ma dernière mise à jour de serveur, php est passé à 7.4 et j'ai dû reconfigurer à la main des fichiers dans Nginx car Debian spécifie les numéros de version, ex: /run/php/php7.4-fpm.sock
 
Pour éviter ce problème j'avais configuré php-fpm pour tourner en tcp, mais la mise à jour du serveur a écrasé mon fichier de configuration sans me demander, donc au final encore du travail manuel.
 
Comment faites-vous?

question architecture, je prends volontiers votre avis.

Pour le moment j'ai un gros serveur de 110Tb qui héberge les fichiers d'un groupe d'utilisateurs.
C'est une grosse partition avec un export NFS unique /share/userdata/
Dans cet export j'ai un dossier par personne
/share/userdata/user1/
/share/userdata/user2/
/share/userdata/user3/
etc.

Sur toutes les station de travail des utilisateurs, ce share nfs est monté dans un dossier
/share/userdata/

J'ai reçu aujourd'hui un 2e serveur vu que le premier est plein et l'idée est de répartir les données entre ces 2 machines.
Le problème du coup c'est que si je fais la même config avec un export unique, je ne vais plus pouvoir garder un seul dossier unique sur les stations de travail. Ca me forcerait à faire un truc du genre
/share/userdata1/
/share/userdata2/
Ce qui mettrais le bronx dans les fichiers de conf des utilisateurs si ils ont des liens ou réf absolues.

Du coup est-ce que je m'amuserais à faire un export nfs par dossier utilisateur et un autofs ou fstab qui monte ça sur les stations de travail ?
Le chiant de l'affaire du coup c'est que lorsqu'un utilisateur part je dois modifier la conf sur toutes les stations

Merci d'avance pour vos avis

EDIT: tiens on dirait qu'on peut mélanger 2 mount NFS dans le même point de montage avec overlayfs, qqn a déjà testé ?

et juste mettre une partie des users sur un serveur et l'autre sur l'autre serveur, sinon ?

Nop, les stations de travail sont utilisées par plusieurs personnes justement.

y'a un truc a essayer : tu montes le userdata2 en NFS sur le vieux serveur. Les répertoires à bouger, tu les bouges sur le point de montage du userdata2.  
Ensuite sur le userdata, tu mets un lien symbolique qui pointe vers le point de montage de userdata2 pour chacun des users déplacés.

overlayfs ?
 

 
ouaip je tente ça sous peu mais il semblerait que ça merdoie avec NFS

hello,
et surtout bonne années les barbus  
 
je galère avec un truc con -_-
depuis une mise à jour, le "dock" (la barre des logiciels favoris qui apparaît quand on passe la souris sur activités) de mon debian/gnome est passé de la gauche au centre-bas (ce que je trouve très con d'un point de vue ergonomie).
et je ne trouve pas comment rétablir ça ...
 

C’est la feature de gnome 40
Demande ici ? https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

ah j'avais jamais vu les topics gnome, merci

 
Bon si jamais le problème est le même sous CentOS    
 

Salut les 'bians.    
 
j'ai un soucis avec mes 'bians. j'ecoute de la zique sur une machine du lan , via une session ssh -X , sur un second tty. depuis un laptop i5 , 2 core + HT.  
ya 8Go de ram sur l'i5 , 4Go de ram sur le core2 duo qui balance la zique. meme OS a savoir debian bulleyes. liaison LAN 1Gbit. les vue metre systems ne montrent rien d'anormal, rien de saturé nul part des 2 cotés.  
 
la paire d'enceinte ne peux pas etre branché , faute de cables assez long sur le laptop. et de toutes façons , je veux comprendre le probleme.
donc , je lance un second server X sur une tty , je ssh -X , puis j'execute firefox , direction youtube , et je balance la zique.  
 
une fois que le son arrive , je ctrl - alt Fx pour revenir sur mes moutons , et au bout de 30 secondes, la zique s'arrete. je re-ctrl-alt-Fx sur la tty qui reçoit le firefox distant , et je vois que cela reprends. tant que je reste sur le TTY qui affriche mon firefox distant , ca tient . si je ssh -X sur une unique TTY , ya aucun probleme.  
 
donc ? question ? pourquoi le firefox distant , injecté sur le second server X , tombe dans les choux au bout de 30 secondes ? noyaux standard , pour l'instant , scheduler CFS si je ne m'abuse. pourquoi le second TTY se met a perdre du temps CPU ? parceque cela y ressemble ...  
 
merci d'avance .    
 

@darxmurf, ha bah ca m'étonne pas, la meme version avec le même bug a du arriver sur la plupart des distros entre temps
 
@driving_south ca serait pas propre à youtube ?
j'ai des effets similaires, ou je lance un onglet sur youtube pour de la zique, puis dans un autre navigateur, sur un autre bureau virtuel, je fais autre choses, et la zique s’arrête assez vite
A tester avec un autre site peut etre ?

 
 
je veux comprendre pourquoi . si c'est l'ordonnanceur par defaut du noyau debian, je veux en changer ... et non , je peux balancer d'autres videos sur le meme bureau virtuel, venant d'un ssh -X , sans que cela coupe . donc non .  
 
c'est autre chose. et je pense que cela vient du local .

tu as essayé de lancer firefox depuis une invite de commande, pour voir d'éventuels messages d'erreur ?
 
sinon en alternative qui ne demande pas de naviguer entre les TTY, tu peux forwarder simplement du flux audio à travers le réseau avec pulse audio, je m'en sers souvent pour un cas d'utilisation similaire au tien (lecteur/navigateur web lancé depuis un PC, audio qui sort des enceintes du PC à côté).

Moi, je passe par Guake pour faire lire une chaîne/playlist YT (ou locale, ça marche aussi) à MPV en mode audio uniquement (format 140 de youtube-l/yt-dlp, paramètre « vid=no » si local), et avec un petit transmetteur FM branché sur la sortie jack, je renvoie le son sur ma chaîne Hi-Fi placée derrière moi et réglée sur la fréquence radio définie sur le transmetteur (108.0 MHz pour être sûr que la fréquence est libre). Et comme ça, pas de fenêtre de terminal ou d’appli audio ouverte en arrière-plan.

 
non aucun message d'erreur sur le terminal.

 
 
je veux AUSSI les lives. quand j'alt tab . donc la video.

 
 
bon, j'ai testé avec chromium. ca passe sans probleme. donc c'est bien du à firefnox.    
pourquoi par contre ? aucune idées.j'ai testsé un le kernel rt. meme probleme sur firefox. pas tres grave , ce sera chromium ;-[

C'est pas une désactivation automatique des onglets en arrière plan pour décharger la mémoire vive?

ha, interessant.. les réglages d'un browser à un autre peuvent varier, que ce soit ceux par défaut ou définis par l'utilisateurs.
je plussoie burn2

Ceux qui ont de l'intel en carte graphique, vous utilisez le driver intel ou le modesetting ?

 
comment firefox saurait - il que je n'ai plus le focus , sachant que je fais que ctrl - alt - Fx , et pas d'alt tab ?  
  . je considere de prime abord , que c'est PAS un perte de focus , car c'est un autre serveur X .

 
Bonne question, tu vois ça où ?  
 

 
Intel je suppose ?

Avec modesetting, j'ai mon écran qui de façon aléatoire devient noir quelques secondes et puis ça revient
 
Je crois que je vais rebasculer sur le driver intel

Pas de soucis d'écran noir chez moi

PS : kernel 5.15.13-amd64

je n'ai ça que sur mon écran en 3440x1440
Pas de souci sur les autres.

Tu dois toucher aux limites de surfaces pouvant être gérées par la puce graphique.  
Par exemple, celui décrit au dessus à BEAUCOUP de mal avec la 4K sur un seul écran.

yes possible que ça vienne de là.
Et si j'essaye de lire un media en 4K, ça rame/lag + écran noir.

 
 
Voilà les infos de mon côté :
 

 
Si ça peut t'aider… (dual screen sous Wayland)

J'aime pas trop ces vagues d'informations au lancement d'un shell