Terminal indique un message d'erreur

plocploc

Membre actif
20 Décembre 2004
459
7
Bonjour

Quand j'ouvre TERMINAL il ne me dit pas bonjour mais
"dyld: shared cached file was build against a different libSystem.dylib, ignoring cache"

En faisant une recherche sur le web, j'ai vu qu'on pouvait tenter de réparer cela en tapant

"sudo update_dyld_shared_cache -force"

Mais là le Terminal me demande un mot de passe... Ok... sauf qu'il ne veut plus rien écrire...

Quelqu'un peut-il m'orienter ?
Merci
Bon week-end !
 
Mais justement ce que j'explique c'est que lorsque Terminal me demande le mot de passe, je n'arrive plus rien à taper !
Le clavier ne répond plus
Etrange, non ?
 
Salut plocploc.

Lorsque une commande sudo déclenche la demande de 'password', le mot-de-passe admin se tape à l'aveugle dans le «Terminal», aucun caractère ne se montrant à la frappe. Ce n'est pas pour autant qu'il n'est pas saisi. Terminer par ↩︎ (retour-chariot : presser la touche 'Entrée' = 'Retour' pour activer la commande).
 
Et chez moi il ne me dit pas bonjour non plus mais "YLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid.
J'ignore ce que cela veut dire, merci à ceux qui voudront m'éclairer si c'est important. Excellentes fêtes de fin d'année aussi à tous.
 
c'est un peu curieux : normalement, ce genre de message survient lorsqu'on lance une application comme sudo. As-tu changé quelque chose dans les fichiers de démarrage du shell ?
 
Non absolument rien de changé et mon Mac Book Pro Rétina mid 2012 va super bien, mais j'ai été surpris de voir cela car j'utilise assez peu le terminal. Sudo je ne sais pas très bien ce que c'est, désolé...
 
Si rien de particulier ne se passe, ce n'est pas très gênant. Je n'ai pas mon Mac sous la main pour vérifier les droits mais c'est sans doute de ce côté qu'il faut chercher.
Tu peux toujours essayer de réparer les droits et autorisations du système.
 
Je venais de passer "la totale" avec Onyx avant de voir cela, curieux mais comme déjà signalé c'est le meilleur portable que j'ai jamais eu, toujours sous ML...

---------- Nouveau message ajouté à 20h26 ---------- Le message précédent a été envoyé à 20h18 ----------

Je relance la Mac avec les 3 "glong" et le terminal indique maintenant "ecutable (/usr/bin/login) is setuid or setgid"...
 
Salut PDD.

le terminal indique maintenant "ecutable (/usr/bin/login) is setuid or setgid"...

/usr/bin/login est un binaire (fichier exécutable natif contenu dans les sous-sols de l'OS) sur lequel sont établies des permissions spéciales. Au lieu d'afficher un honnête r-x (permission de lecture = read + exécution = execute, sans droit d'édition = write) - ce pour le propriétaire = root, le groupe-système = wheel et éventuellement - selon les fichiers - pour n'importe qui ou pour personne d'autre), ce qui donnerait en standard : -r-xr-xr-x ; on peut lire un curieux : -r-sr-sr-s .

Ce 's' à la place du 'x' signifie que les permissions setuid et setgid sont établies sur l'exécutable. Setuid (instauration d'une identité d'utilisateur) autorise un processus à exécuter un binaire non plus avec les droits de l'utilisateur qui l'a initié, mais avec les droits du propriétaire du binaire, qui est root ; de même, setgid (instauration d'un identité de groupe) autorise un processus à exécuter un binaire non plus avec les droits du groupe dont fait partie l'utilisateur qui l'a initié, mais avec ceux du groupe-système wheel. Il s'agit donc d'un passe-droit établi sur un exécutable déterminé qui permet au processus qui l'utilise d'emprunter les droits-système les plus élevés, quel que soit le niveau d'autorisation préalable de l'utilisateur initiataire.

En abrégé de ces abstruses considérations : tu n'as pas à t'inquiéter du fait que le binaire : /usr/bin/login soit affecté des passe-droits setuid et setgid - c'est là son statut par défaut dans l'OS.


La seule chose curieuse est que ce statut 'réglementaire' de permissions exceptionnelles sur l'exécutable login déclenche des commentaires de la part du «Terminal», le tien du moins . Le mien ne dit pas plus 'bonjour' qu'aucun autre, mais m'épargne aussi pareilles remarques incongrues sur l'état de droit de tel ou tel exécutable.

Le message intempestif s'affichant en cas de passation d'une commande sudo (Super-Administrateur Système) :

Bloc de code:
DYLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid

a été reporté comme un bug mineur sous «Mountain Lion». Je ne savais pas qu'il pouvait perdurer sous «Mavericks (peut-être à la suite d'une installation en mise-à-niveau d'un 10.8 sous lequel il pré-existait?). Maintenant, tu déclares qu'un autre message s'affiche dans le «Terminal» (toujours à l'occasion d'une commande sudo? Ou d'entrée de lancement du shell?) :

Bloc de code:
excutable "/usr/bin/login" is setuid or setgid

Comme vu ci-dessus, la situation est 'réglementaire' et n'appelle aucune correction. Ni aucune remarque dans le «Terminal», normalement.

Ce que je me figure, est qu'un processus sur ton Mac utilise le passe-droit setuid ou setgid pour exécuter le binaire : login avec l'identité effective ('effective ID') de root ou de membre du groupe-système wheel. Pour je ne sais quelle raison, cette utilisation de permissions d'exception qui néanmoins sont réglementairement en place sur ce binaire a une répercussion dans le «Terminal» - lequel se fait l'écho de cet événement. Le déclencheur est-il, en amont, une application ou une extension que tu as ajoutée et qui serait amenée à utiliser le binaire : login? C'est ce qu'il conviendrait de diagnostiquer, au cas où tu voudrais éradiquer le message dans le «Terminal» qui réagit à cette utilisation du binaire. Mais je te déconseillerais vivement d'envisager de changer les permissions sur ce dernier, pour les ramener à un classique : -r-xr-xr-x, sous peine de bloquer d'éventuels usages en passe-droits de cet exécutable.
 
Dernière édition par un modérateur:
Merci pour ces explications forts complètes. Il est possible que mes petits enfants qui vont régulièrement chercher des jeux sur l'ApSt (ou autre part!) soient la cause de cette observation...