[résolu] Qui gère les communication entre applications et disque?

Support Debian
#1

Bonjour,
j’ai depuis quelques jours un souci avec certains programmes : les tentatives de communication (chargement, enregistrement) avec le disque bloquent l’application. :
C’est par exemple dans la console de téléchargement de Firefox, le clic sur ‘ouvrir le dossier’ gèle l’application. Rien d’anormal n’apparaît dans le gestionnaire de tâches, et le reste du système fonctionne.
Certaines applications ne sont pas touchées (libre office).
je suppose que je dois réinstaller un paquet, mais lequel?
Merci pour vos idées
Phil

PS : debian stretch XFCE

#2

Bonjour,

Le kernel.

Est-ce que tu pourrais nous donner plus d’indications sur les applications qui rencontrent ce problème ?

Le problème est-il le même quand tu ouvres le gestionnaire de fichiers (d’ailleurs, quel est-il est quel est l’environnement graphique ?) ?

Je soupçonne qu’il s’agisse plutôt d’un freeze graphique et qu’il n’y a pas de problèmes de lecture/écriture sur disque (enfin, j’espère).

#3

Merci de la réponse
Debian9 XFCE lightDM
gestionnaire de fichier Caja, mais je n’ai pas désinstallé Thunar.
Le gestionnaire fonctionne sans problème.
C’est plutôt un processus défaillant… et pas de freeze graphique… xorg ok!

J’ai travaillé avec pas mal d’applications audio et video ces derniers temps. Supression de ces applications puis mise à jour. Je suppose que c’est là que ça a buggé…
Le problème est d’abord apparu avec kdenlive puis openshot. Je l’ai ensuite remarqué avec la bibliothèque de firefox.

#4

[quote=“phil2, post:3, topic:75068”]J’ai travaillé avec pas mal d’applications audio et video ces derniers temps.[/quote]Tu n’aurais pas un disque un peu trop rempli ? Que dit
df -h | grep ^/

#5

Désolé, j’ai dû m’absenter

Non,non je fais le ménage! :wink:
il reste 30% libre, mais le souci est le même quelle que soit la taille du fichier. D’ailleurs, vu le souci avec Firefox, c’est vraiment un souci de communication. ça fait comme si l’ordre n’arrivait pas à l’explorateur de fichiers…
mais pas de PB avec Thunderbird…
Je sèche

#6

Peux-tu te créer un profile test de Firefox pour comparer ce qui se passe.
firefox -P

#7

Je viens de tester en ouvrant une session en root et j’ai le même souci. (au cas où ce serait un problème de droits…)
Idem pour < firefox -P>

#8

C’est une blague ou quoi ???
C’est quoi cette manie d’ouvrir des applications graphiques en root ??? (on voit ça souvent ici, bizarrement).
D’où vient exactement cette idée stupide ?

'+ quelle version de Firefox exactement ? Quelle provenance ?

#9

Cette idée stupide vient de quelqu’un qui tente une réflexion pour résoudre un souci lié au système d’exploitation. La documentation Linux est parfois inexistante et il faut bien essayer des choses pour avancer. ça m’a permis d’écarter la question des droits…

Le souci n’est pas lié à la version de firefox (désinstallé et réinstallé entre-temps) puisque le même souci se produit avec d’autres logiciels. Je cherche parmi les démons gérés par systemd…

#10

Thunderbird => no problem
Firefox => problem

Ça parait étrange.
systemctl -a | egrep "udev|udisk"

#11

Bien d’accord sur l’étrangeté

systemd-udev-trigger.service
loaded active exited udev Coldplug all Devices
systemd-udevd.service
loaded active running udev Kernel Device Manager
udisks2.service
loaded active running Disk Manager
systemd-udevd-control.socket
loaded active running udev Control Socket
systemd-udevd-kernel.socket
loaded active running udev Kernel Socket

#12

systemctl -a | egrep “sda|sdb”

#13

dev-sda.device loaded active plugged MAXTOR_STM3320820AS
dev-sda1.device loaded active plugged MAXTOR_STM3320820AS Sauvegardes
dev-sda4.device loaded active plugged MAXTOR_STM3320820AS
dev-sdb.device loaded active plugged Hitachi_HDT725032VLA380
dev-sdb1.device loaded active plugged Hitachi_HDT725032VLA380 1
dev-sdb2.device loaded active plugged Hitachi_HDT725032VLA380 2
dev-sdb3.device loaded active plugged Hitachi_HDT725032VLA380 3
dev-sdb5.device loaded active plugged Hitachi_HDT725032VLA380 5
sys-devices-pci0000:00-0000:00:08.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loaded active plugged MAXTOR_STM3320820AS Sauvegardes
sys-devices-pci0000:00-0000:00:08.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda4.device loaded active plugged MAXTOR_STM3320820AS
sys-devices-pci0000:00-0000:00:08.0-ata1-host0-target0:0:0-0:0:0:0-block-sda.device loaded active plugged MAXTOR_STM3320820AS
sys-devices-pci0000:00-0000:00:08.0-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb1.device loaded active plugged Hitachi_HDT725032VLA380 1
sys-devices-pci0000:00-0000:00:08.0-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb2.device loaded active plugged Hitachi_HDT725032VLA380 2
sys-devices-pci0000:00-0000:00:08.0-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb3.device loaded active plugged Hitachi_HDT725032VLA380 3
sys-devices-pci0000:00-0000:00:08.0-ata2-host1-target1:0:0-1:0:0:0-block-sdb-sdb5.device loaded active plugged Hitachi_HDT725032VLA380 5
sys-devices-pci0000:00-0000:00:08.0-ata2-host1-target1:0:0-1:0:0:0-block-sdb.device loaded active plugged Hitachi_HDT725032VLA380
dev-sda4.swap loaded active active /dev/sda4
dev-sdb2.swap loaded active active /dev/sdb2

#14

Je dois partir. Merci du coup de main, je m’y recolle ce soir…

#15

j’ai pisté les appels de Firefox avec strace voici l’endroit où ça bloque lorsque j’appelle le dossier téléchargements depuis la bibliothèque :

stat("/home/moi/T\303\251l\303\251chargements/truc.pdf", {st_mode=S_IFREG|0644, st_size=4038416, …}) = 0
— SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TKILL, si_pid=1549, si_uid=1000} —
— SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TKILL, si_pid=1549, si_uid=1000} —
— SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TKILL, si_pid=1549, si_uid=1000} —
— SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TKILL, si_pid=1549, si_uid=1000} —
(…)

Dans le gestionnaire de tâches j’ai en même temps un nouveau processus dbus-daemon qui s’ouvre mais semble n’effectuer aucune tâche…

Une idée?

EDIT :
Nouvelle tentative, sur les mêmes fichiers: l’appel fonctionne. Je n’ai rien changé au système entre temps. Ni à firefox. ni aux fichiers…

#16

J’aurais tendance à soupçonner une incohérence de librairies.
Première vérification : les sources de paquets sont-elles cohérentes ?
https://wiki.debian.org/fr/SourcesList
Quelle était la provenance des applications vidéo évoquées ?

#17

Bonjour
Oui, c’est possible.
J’ai supprimé les sources de paquets non-fiables après installation, et avant la mise à jour, mais il peut rester quelques paquets intrus.
Voici mon sources.list

# deb cdrom:[Debian GNU/Linux 9.1.0 _Stretch_ - Official amd64 xfce-CD Binary-1 20170722-11:29]/ stretch main 

# deb cdrom:[Debian GNU/Linux 9.1.0 _Stretch_ - Official amd64 xfce-CD Binary-1 20170722-11:29]/ stretch main 

deb http://ftp.fr.debian.org/debian/ stretch contrib non-free main 
# deb-src http://ftp.fr.debian.org/debian/ stretch main non-free contrib 

deb http://security.debian.org/debian-security/ stretch/updates non-free contrib main 
# deb-src http://security.debian.org/debian-security/ stretch/updates main contrib non-free 

# stretch-updates, previously known as 'volatile'
deb http://ftp.fr.debian.org/debian/ stretch-updates main contrib non-free 
# deb-src http://ftp.fr.debian.org/debian/ stretch-updates main contrib non-free 

# stretch-backports, previously on backports.debian.org
deb http://ftp.fr.debian.org/debian/ stretch-backports main contrib non-free 
# deb-src http://ftp.fr.debian.org/debian/ stretch-backports non-free contrib main

Je viens de remarquer que si j’attends assez longtemps, firefox finit par ouvrir le dossier téléchargements. Par la suite, les appels se font normalement.

#18

Un petit coup d’apt update et apt upgrade (en root) ?

#19

C’est fait
Il ne restait que les dernières versions du noyau à mettre à jour.

pas de changement…

#20

Ça serais pas une défaillance matériel ? Secteur défectueux ou un truc du genre ? Que voie tu dans le syslog ?