date:20210906

Re: error while loading shared libraries: libmandb-2.9.4.so

2021-09-06 Par sujet BERTRAND Joël

NoSpam a écrit :
> Bonsoir, avec debian11, pour comparaison taille et droits
> 
> root@keewi:~# ls -al /usr/lib/man-db/libmandb*
> -rw-r--r-- 1 root root 30712 19 févr.  2021
> /usr/lib/man-db/libmandb-2.9.4.so
> lrwxrwxrwx 1 root root    17 19 févr.  2021 /usr/lib/man-db/libmandb.so
> -> libmandb-2.9.4.so

hilbert:[~] > ls -al /usr/lib/man-db/libmandb*
-rw-r--r-- 1 root root 30712 19 févr.  2021
/usr/lib/man-db/libmandb-2.9.4.so
lrwxrwxrwx 1 root root17 19 févr.  2021 /usr/lib/man-db/libmandb.so
-> libmandb-2.9.4.so
hilbert:[~] >

La machine est diskless et je trouve dans les logs :
Sep  6 18:34:10 hilbert kernel: [549158.719413] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719418] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719423] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719427] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719432] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719439] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719444] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719449] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719453] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719459] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719463] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719468] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719472] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719477] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719482] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719487] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719492] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719497] nfs: RPC call returned
error 13
Sep  6 18:34:10 hilbert kernel: [549158.719501] nfs: RPC call returned
error 13

Je suppose que ça correspond à tous les essais que je vois dans strace.
En dehors de ce problème, la machine fonctionne parfaitement.

Bien cordialement,

JKB

Re: error while loading shared libraries: libmandb-2.9.4.so

2021-09-06 Par sujet NoSpam


Bonsoir, avec debian11, pour comparaison taille et droits

root@keewi:~# ls -al /usr/lib/man-db/libmandb*
-rw-r--r-- 1 root root 30712 19 févr.  2021 
/usr/lib/man-db/libmandb-2.9.4.so
lrwxrwxrwx 1 root root    17 19 févr.  2021 /usr/lib/man-db/libmandb.so 
-> libmandb-2.9.4.so



Le 06/09/2021 à 18:20, BERTRAND Joël a écrit :

Bonsoir à tous,

Depuis quelque temps, j'ai l'erreur suivante en appelant man :

Root hilbert:[/usr/lib] > man top
man: error while loading shared libraries: libmandb-2.9.4.so: cannot
open shared object file: Permission denied

Pourtant, toutes les bibliothèques semblent être là :

Root hilbert:[/usr/lib] > ldd /usr/bin/man
 linux-vdso.so.1 (0x7ffd118f2000)
 libmandb-2.9.4.so => /usr/lib/man-db/libmandb-2.9.4.so
(0x7fc5f3453000)
 libman-2.9.4.so => /usr/lib/man-db/libman-2.9.4.so
(0x7fc5f341)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc5f3399000)
 libpipeline.so.1 => /usr/lib/x86_64-linux-gnu/libpipeline.so.1
(0x7fc5f3388000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc5f31c3000)
 libgdbm.so.6 => /usr/lib/x86_64-linux-gnu/libgdbm.so.6
(0x7fc5f31b)
 libseccomp.so.2 => /usr/lib/x86_64-linux-gnu/libseccomp.so.2
(0x7fc5f318b000)
 /lib64/ld-linux-x86-64.so.2 (0x7fc5f347b000)
Root hilbert:[/usr/lib] >

J'ai réinstallé man-db sans obtenir de meilleur résultat.

Les droits me semblent corrects :

Root hilbert:[/usr/lib/man-db] > ls -al
total 420
drwxr-xr-x   2 root root   1024  6 sept. 18:03 .
drwxr-xr-x 141 root root  11264  6 sept. 15:48 ..
-rwxr-xr-x   1 root root  23232 19 févr.  2021 globbing
-rw-r--r--   1 root root 271168 19 févr.  2021 libman-2.9.4.so
-rw-r--r--   1 root root  30712 19 févr.  2021 libmandb-2.9.4.so
lrwxrwxrwx   1 root root 17 19 févr.  2021 libmandb.so ->
libmandb-2.9.4.so
lrwxrwxrwx   1 root root 15 19 févr.  2021 libman.so -> libman-2.9.4.so
lrwxrwxrwx   1 root root 13 19 févr.  2021 man -> ../../bin/man
-rwxr-xr-x   1 root root  23392 19 févr.  2021 manconv
lrwxrwxrwx   1 root root 15 19 févr.  2021 mandb -> ../../bin/mandb
-rwxr-xr-x   1 root root  56096 19 févr.  2021 zsoelim

et il s'agit bien d'une bibliothèque partagée :
Root hilbert:[/usr/lib/man-db] > file libmandb-2.9.4.so
libmandb-2.9.4.so: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked,
BuildID[sha1]=c20b1c94193b241e4e17834335605b9d68db1632, stripped

Si j'essaie de lancer man dans strace, je m'aperçois que le loader
cherche libmandb partout sauf dans /usr/lib/man-db :

Root hilbert:[/usr/lib/man-db] > strace man top 2>&1 | grep libmandb
openat(AT_FDCWD, "/usr/lib/man-db/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun

error while loading shared libraries: libmandb-2.9.4.so

2021-09-06 Par sujet BERTRAND Joël

Bonsoir à tous,

Depuis quelque temps, j'ai l'erreur suivante en appelant man :

Root hilbert:[/usr/lib] > man top
man: error while loading shared libraries: libmandb-2.9.4.so: cannot
open shared object file: Permission denied

Pourtant, toutes les bibliothèques semblent être là :

Root hilbert:[/usr/lib] > ldd /usr/bin/man
linux-vdso.so.1 (0x7ffd118f2000)
libmandb-2.9.4.so => /usr/lib/man-db/libmandb-2.9.4.so
(0x7fc5f3453000)
libman-2.9.4.so => /usr/lib/man-db/libman-2.9.4.so
(0x7fc5f341)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc5f3399000)
libpipeline.so.1 => /usr/lib/x86_64-linux-gnu/libpipeline.so.1
(0x7fc5f3388000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc5f31c3000)
libgdbm.so.6 => /usr/lib/x86_64-linux-gnu/libgdbm.so.6
(0x7fc5f31b)
libseccomp.so.2 => /usr/lib/x86_64-linux-gnu/libseccomp.so.2
(0x7fc5f318b000)
/lib64/ld-linux-x86-64.so.2 (0x7fc5f347b000)
Root hilbert:[/usr/lib] >

J'ai réinstallé man-db sans obtenir de meilleur résultat.

Les droits me semblent corrects :

Root hilbert:[/usr/lib/man-db] > ls -al
total 420
drwxr-xr-x   2 root root   1024  6 sept. 18:03 .
drwxr-xr-x 141 root root  11264  6 sept. 15:48 ..
-rwxr-xr-x   1 root root  23232 19 févr.  2021 globbing
-rw-r--r--   1 root root 271168 19 févr.  2021 libman-2.9.4.so
-rw-r--r--   1 root root  30712 19 févr.  2021 libmandb-2.9.4.so
lrwxrwxrwx   1 root root 17 19 févr.  2021 libmandb.so ->
libmandb-2.9.4.so
lrwxrwxrwx   1 root root 15 19 févr.  2021 libman.so -> libman-2.9.4.so
lrwxrwxrwx   1 root root 13 19 févr.  2021 man -> ../../bin/man
-rwxr-xr-x   1 root root  23392 19 févr.  2021 manconv
lrwxrwxrwx   1 root root 15 19 févr.  2021 mandb -> ../../bin/mandb
-rwxr-xr-x   1 root root  56096 19 févr.  2021 zsoelim

et il s'agit bien d'une bibliothèque partagée :
Root hilbert:[/usr/lib/man-db] > file libmandb-2.9.4.so
libmandb-2.9.4.so: ELF 64-bit LSB shared object, x86-64, version 1
(SYSV), dynamically linked,
BuildID[sha1]=c20b1c94193b241e4e17834335605b9d68db1632, stripped

Si j'essaie de lancer man dans strace, je m'aperçois que le loader
cherche libmandb partout sauf dans /usr/lib/man-db :

Root hilbert:[/usr/lib/man-db] > strace man top 2>&1 | grep libmandb
openat(AT_FDCWD, "/usr/lib/man-db/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/tls/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/usr/lib/man-db/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/lib/x86_64-linux-gnu/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission non accordée)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/tls/haswell/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/tls/x86_64/libmandb-2.9.4.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
openat(AT_FDCWD,

Problème avec le sélecteur de fichier GTK et montage NFS

2021-09-06 Par sujet Frédéric MASSOT


Bonjour,

Depuis plusieurs mois, j'ai un bug avec le sélecteur de fichier de GTK 
lors des accès au serveur de fichier monté en NFS.


Dans une application qui utilise GTK, dans le sélecteur de fichier, je 
me déplace dans un dossier monté en NFS, dès que je tape quelques 
lettres pour filtrer les dossiers et fichiers, la liste devient vide.


Ce bug ne se produit pas lors d'accès à des dossiers locaux, lorsque 
l'on tape quelques lettres la liste des dossiers et fichiers s'affine et 
affiche le résultat de la recherche.


Le bug est apparu après la mise à jour du paquet libgtk-3-0 version 
3.24.20. J'ai des PC qui n'ont pas été mis à jour et le sélecteur de 
fichier fonctionne correctement.


J'ai ouvert deux rapports de bug en décembre et janvier :

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976334
- https://gitlab.gnome.org/GNOME/gtk/-/issues/3579

mais je n'ai eu aucun retour.

Pour le montage NFS, j'utilise ces options :
rw,tcp,hard,nosuid,relatime,user,noauto,x-systemd.automount,_netdev


J'aimerai bien savoir si je suis le seul dans ce cas et d'où vient le 
problème ?


Est-ce qu'il y a des utilisateurs ayant un montage NFS sur la liste ?


Merci.
--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: mise à jour Buster vers Bullseye

2021-09-06 Par sujet Sébastien NOBILI


Bonjour,

Le 2021-09-05 11:24, Jean-Michel OLTRA a écrit :
Je viens d'achever cette nuit mes dernières mises à jour de 7 serveurs 
de
Buster à Bullseye. Ce ne sont pas des serveurs très complexes, mais il 
y

avait quelques bases de données sous Postgresql avec Pgpool2.

Aucune mauvaise surprise et tout s'est parfaitement déroulé.


Je n'ai pas encore pris le temps de migrer mon serveur et sa flotte de 
conteneurs,
mais je constate que chaque version de Debian devient de plus en plus 
simple à
mettre à jour (20 min max. pour les différents systèmes que j'ai mis à 
jour en

Bullseye jusqu'à présent et aucune mauvaise surprise).

Je tenais juste, par ce courriel, à remercier les équipes de Debian 
dont

la qualité du travail permet ce genre d'opération.


J'abonde totalement dans ton sens :)

Sébastien

qui utilise Frama-C ?

2021-09-06 Par sujet Basile Starynkevitch


Bonjour la liste,


Qui (parmi les lecteurs de la liste) utilise l'analyseur Frama-C 
 (voir https://frama-c.com/  
...) et pourquoi?


Merci de me répondre en privé vers bas...@starynkevitch.net 



PS. Significativement, aucun paquet Debian ne semble avoir été analysé 
par Frama-C. Votre opinion sur le pourquoi est appréciée.


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

transparents sur GNU bash

2021-09-06 Par sujet Basile Starynkevitch


Bonjour la liste,


dans quelques heures je fais un TD sur GNU bash. Les transparents (dans 
leur état actuel) sont disponibles en 
http://starynkevitch.net/Basile/Bash-Starynkevitch-transp.pdf 




Vos commentaires sont bienvenus, à la fois vers 
basile.starynkevi...@cea.fr et vers bas...@starynkevitch.net



Merci

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: error while loading shared libraries: libmandb-2.9.4.so

Re: error while loading shared libraries: libmandb-2.9.4.so

error while loading shared libraries: libmandb-2.9.4.so

Problème avec le sélecteur de fichier GTK et montage NFS

Re: mise à jour Buster vers Bullseye

qui utilise Frama-C ?

transparents sur GNU bash

7 matches

Site Navigation

Mail list logo

Footer information