Forum Linux.général problème d'exécution de bashrc lors du lancement d'un shell

Posté par andrias le 20 juin 2020 à 21:42. Licence CC By‑SA.

Étiquettes :

juin

2020

Bonjour à tous

Nouveau venu sur ce forum, je ne suis pas certain que ce soit le bon endroit pour publier ce post, si ce n'est pas le cas, merci de me le faire savoir.

J'ai une machine qui tourne sous Mandriva 2006 depuis un nombre d'années assez conséquent, et dernièrement, il est apparu un problème que je ne suis pas parvenu à expliquer : lors de l'ouverture d'un shell (bash) que ce soit via un login console ou un "su -", les fichiers /etc/bashrc et /etc/profile ~/.profile et ~/.bashrc ne sont plus exécutés, de sorte que je suis obligé de les lancer à la main en tapant explicitement
$ . ~/.bashrc
Le problème se manifeste pour tous les comptes utilisateurs, à l'exception de 'root' pour qui tout fonctionne correctement.

Il a dû se passer quelque chose dans le système, mais je ne sais pas quoi. J'ai vérifié les grands classiques:
-- partition pleine rendant impossible l'écriture de fichiers ? => non
-- fichier /etc/bashrc ou /etc/profile effacé, corrompu ou interdit en lecture ? => non

Donc, je sèche. Quelqu'un aurait-il des pistes ?

Merci d'avance

# Fichiers d'initialisation bash

Posté par JJD le 21 juin 2020 à 07:57. Évalué à 3.

Salut,

Les fichiers /etc/bashrc et ~/.bashrc sont interprétés au démarrage de bash s'il s'agit d'un shell interactif qui n'est pas un shell de connexion (login ou "su -" par exemple).

Lors du démarrage d'un shell de connexion, ce sont les fichiers /etc/profile puis ~/.bash_profile ou ~/.bash_login ou ~/.profile qui sont utilisés. Si l'on veut que les fichiers bashrc soient également lus, il faut donc inclure cette lecture dans /etc/profile ou ~/.profile (mais il me semble que c'est généralement fait dans les fichiers inclus par les distributions).

Peut-être que le fichier /etc/profile a été modifié sur ta machine et n'appelle plus /etc/bashrc.
Si ça fonctionne pour root, c'est soit parce que le fichier .profile de root appelle explicitement les fichiers bashrc, soit parce que la session root n'a pas un shell de connexion (appel avec su ou sudo sans les options "-" ou "-i")
- [^] # Re: Fichiers d'initialisation bash
  
  Posté par vv222 (site web personnel) le 21 juin 2020 à 11:57. Évalué à 2.
  L’extrait pertinent de mon fichier ~/.profile, issu d’une Debian mais probablement fonctionnel à peu près partout :
```
# if running bash
if [ -n "$BASH_VERSION" ] && [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
fi
```
  Attention, si ~/.bash_profile ou ~/.bash_login est présent, ~/.profile est ignoré par Bash.
- [^] # Re: Fichiers d'initialisation bash
  
  Posté par andrias le 21 juin 2020 à 16:42. Évalué à 2. Dernière modification le 22 juin 2020 à 15:33.
  Bonjour JDD, merci pour ta réponse, mais ça ne fait pas avancer mon problème. Tout ça je le sais déjà, quoique je ne me suis jamais posé la question de savoir dans quel ordre étaient lus /etc/bashrc, /etc/profile, ~/.bashrc et ~/.profile.
  
  J'ai rajouté au début de chacun de ces fichiers une ligne de traçage :
  
  echo "lancement de /etc/profile" # dans /etc/profile
  et l'équivalent dans /etc/bashrc, ~/.profile, ~/.bashrc
  
  … et voilà ce que ça donne pour un login root (qui n'a pas de fichier .profile) :
```
-bash-3.00$ su -
Password: 
lancement de /etc/profile
lancement de /root/.bashrc
lancement de /etc/basrc
[root@pc-126 ~]#
```
  … et voilà ce que ça donne pour un login toto
```
-bash-3.00$ su - toto
Password: 
-bash-3.00$ whoami
toto
-bash-3.00$
```
  Je suis bien logué sous toto, mais aucun des fichiers /etc/profile, /etc/bashrc, ~toto/.bashrc, ~toto/.profile n'a été exécuté. Pourtant ils sont bien là (le login de root les exécute sans problème) et ils ont les bons droits (du moins il me semble) :
```
-bash-3.00$ ls -l /etc/profile /etc/bashrc
-rw-r--r--  1 root root 944 Jun 21 09:24 /etc/bashrc
-rw-r--r--  1 root root 963 Jun 21 09:23 /etc/profile
-bash-3.00$
```
  Bref, tout devrait fonctionner, ça fonctionnait d'ailleurs parfaitement jusqu'à cette semaine, et ça ne fonctionne plus, sans que j'arrive pas à comprendre pourquoi. J'en suis donc à chercher des pistes.
  - [^] # Re: Fichiers d'initialisation bash
    
    Posté par NeoX le 22 juin 2020 à 15:45. Évalué à 2.
    chez moi le ~/.bashrc de l'utilisateur est appelé par le ~/.profile de celui-ci
    attention le ~ depend de chaque utilisateur évidemment.
    
    donc /root/.profile appelle /root/.bashrc
    mais /home/user/.profile appelle /home/user/.bashrc
    
    avec une condition
    
    This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
    
    exists.
    
    il ne faut pas qu'un .bash_profile ou .bash_login existe.
    et
    .profile quand le shell est un login (login ssh, su - …)
    .bashrc directement quand le shell n'est pas un login
    
    ensuite il faut voir le contenu de /etc/profile
    ce dernier fait peut-être une sortie ou une action différente selon qu'on est root ou non.
    
    chez moi il change le PATH par exemple
```
if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
```
    et c'est le /etc/profile qui charge le /etc/bash.bashrc
```
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
```
    - [^] # Re: Fichiers d'initialisation bash
      
      Posté par Loïs Taulelle ࿋ (site web personnel) le 22 juin 2020 à 18:01. Évalué à 1.
      
      Je rajoute, si ça peut aider :
      
      https://blog.flowblok.id.au/2013-02/shell-startup-scripts.html
      
      Proverbe Alien : Sauvez la terre ? Mangez des humains !
    - [^] # Re: Fichiers d'initialisation bash
      
      Posté par andrias le 23 juin 2020 à 10:33. Évalué à 1.
      
      Bonjour NeoX, et merci du tuyau, mais la présence ou l'absence de bash_profile ou bash_login ne semble pas jouer ici :
      
      aucun des comptes utilisateurs n'a de ~/.bash_login, certains ont un ~/.bash_profile et d'autre non, mais ils sont tous traités à la même enseigne : hormis ROOT, aucun n'a ses fichiers de démarrage lancés à l'ouverture de BASH
# HS

Posté par ʭ ☯ le 21 juin 2020 à 15:27. Évalué à 3.

Je suis hors-sujet, mais je suis curieux de la raison pour rester avec des logiciels d'il y a 14 ans? Un pilote graphique abandonné?

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: HS
  
  Posté par andrias le 21 juin 2020 à 16:59. Évalué à 2.
  
  C'est ma plate-forme de développement : en 25 ans j'ai écrit à mon usage personnel et professionnel des tonnes et des tonnes de programmes et d'utilitaires, en C, C++, lex/yacc, bash, awk, perl, php et j'en passe, et j'en avais marre de passer ma vie à les upgrader à chaque fois que je changeais de version des compilateurs, voire carrément de distribution. J'en suis venu à adopter une ligne de conduite très simple : tant qu'une installation fonctionne, je la garde.
  Alors bien sûr, quand je veux surfer sur le web, lire des vidéos en streaming, etc. etc., j'ai un autre ordi qui tourne sous une version plus récente de Mandriva, mais le coeur de mes applis, ma comptabilité, mes utilitaires … reste sous Mandriva 2006.
  - [^] # Re: HS
    
    Posté par ʭ ☯ le 21 juin 2020 à 18:58. Évalué à 3.
    
    Merci pour ta réponse, je n'aurais jamais imaginé cette raison, elle tient tant qu'on ne veut pas profiter des améliorations du monde qui nous entoure. Heureusement que tu n'as pas commencé il y a 40 ans, tu serais encore à faire ta compta sur un Z80 ;-)
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: HS
    
    Posté par NeoX le 22 juin 2020 à 15:32. Évalué à 1.
    
    C'est ma plate-forme de développement
    
    de développement PERSO alors,
    parce qu'un code développé y a 25ans
    
    et j'en avais marre de passer ma vie à les upgrader
    
    sans mise à jour,
    
    ca doit pas etre simple à utiliser sur les distributions plus récentes.
    - [^] # Re: HS
      
      Posté par ʭ ☯ le 22 juin 2020 à 23:28. Évalué à 2.
      
      Il faut lire des fois : la question était pourquoi il reste sur une Mandriva 2006, donc oui il ne l'utilise pas sur une distribution récente!
      
      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# recadrage

Posté par andrias le 23 juin 2020 à 10:42. Évalué à 1.

Bonjour et merci à tous de répondre, mais il me semble nécessaire de recadrer un peu les choses :

-- d'abord, l'objet de ce post n'est pas de discuter des avantages et des inconvénients à travailler en 2020 avec une distribution datant de 2006. Moi je veux bien en discuter, mais dans un autre post, ici c'est hors sujet, à moins qu'on m'explique que mon problème est spécifiquement lié à l'âge de ma distribution.

-- ensuite, les subtilités de l'ordre et des renvois de lecture de tous les fichiers bash_rc, bash_login, profile, etc. sont elles aussi à côté de la plaque, car comme je l'ai précisé à plusieurs reprises, mon problème est qu'AUCUN de ces fichiers n'est lu au démarrage du shell, quel que soit l'utilisateur, à l'exception de ROOT. Et c'est apparu soudainement, après des années de fonctionnement correct de ma plate-forme de travail.

Par expérience, quand un problème de cet ordre apparaît (ça marchait et ça ne marche plus) sans que j'ai fait quoi que ce soit de spécial, c'est généralement un truc bête du genre :
-- la partition sur laquelle le système écrit des fichiers temporaires, ou des fichiers de log, ou d'autres fichiers … est pleine
-- des fichiers nécessaires au fonctionnement de l'application ont été effacés, corrompus, ou leurs droits ont été modifiés par accident sans que je m'en rende compte
-- (en théorie, ça ne m'est encore jamais arrivé sous LINUX) : un virus informatique

Or, dans le cas présent, les fichiers de lancement (bashrc, profile …) sont là, ils fonctionnent parfaitement puisque je peux, une fois le shell démarré, les lancer à la main en tapant par exemple

$ . ~/.bashrc

Je m'en suis assuré en plaçant EN TÊTE DE CHACUN DE CES FICHIERS, avant toute autre instruction, une ligne de traçage

echo "lancement de (nom du fichier)"

… et la question est : pourquoi aucun des fichiers de démarrage n'est-il lu ?

La faute à BASH lui-même ? la faute à LOGIN / SU qui lancerait BASH avec de mauvais arguments ?

Je sèche lamentablement, d'où cet appel à l'aide, et si ça continue, je vais finir par adopter la solution extrême : réinstaller le système d'exploitation (ce que je ne peux malheureusement pas faire pour l'instant car je n'ai pas sous la main de DVD d'installation)

En attendant je reste ouvert à toutes les pistes … merci d'avance
- [^] # Re: recadrage
  
  Posté par Kerro le 23 juin 2020 à 18:36. Évalué à 3.
  
  Si j'étais dans la même situation je commencerais par tracer l'exécution de su et de ses descendants avec strace. Un premier test avec strace -r su xxxx, la suite dépend de ce que je trouve.
  
  l'objet de ce post n'est pas de discuter des avantages et des inconvénients à travailler en 2020 avec une distribution datant de 2006
  
  Personne ne t'oblige à répondre à ces questions.
  D'un autre côté, lorsqu'une personne fait quelque chose qui est en dehors des habitudes ou du raisonnable, il est fréquent qu'on soit curieux.
  
  Par exemple je suis curieux de savoir pourquoi tu n'as pas encore utilisé strace alors que tu galères depuis plusieurs jours, parce que c'est un outil sur lequel tu devrais rapidement tomber en cherchant des solutions via un moteur de recherche. D'autant plus que tu te poses la question de savoir si c'est su/login/bash qui merde. Du coup je ne pose pas la question :-)
  - [^] # Re: recadrage
    
    Posté par NeoX le 23 juin 2020 à 20:32. Évalué à 3.
    
    Par exemple je suis curieux de savoir pourquoi tu n'as pas encore utilisé strace
    
    bon on n'est pas vendredi, et je suis taquin, je dirais donc peut-être parce que ca n'existait pas en 2006 ? ;)
    - [^] # Re: recadrage
      
      Posté par Kerro le 24 juin 2020 à 00:03. Évalué à 3.
      
      Effectivement. Il faut peut-être qu'il pose la question sur un forum de gens bloqués en 2006.
      
      Il reste à vérifier les logs (ça non plus il n'a pas fait, pourtant c'est la base de la base), vérifier les permissions (la base également), renommer su/login/etc et les remplacer par le nécessaire pour capturer les arguments, etc.
      - [^] # Re: recadrage
        
        Posté par andrias le 24 juin 2020 à 23:41. Évalué à 1.
        
        Kerro,
        
        Les forums de gens bloqués en 2006 sur ce problème-là, si tu en trouves, dis-le moi je suis preneur. Avant de me décider à poster sur ce forum, j'ai quand même cherché un peu sur le web si le problème n'avait pas été posé auparavant, bien sûr. Je n'ai rien trouvé, d'où ce post.
        
        Je suis d'accord avec toi que regarder les logs et vérifier les permissions, c'est la base de la base, et ça fait partie des choses que j'ai faites avant d'appeler de l'aide sur ce forum. Mea culpa, j'ai oublié de le préciser dans mes posts précédents :
        
        -- j'ai été éplucher les fichiers du répertoire /var/log sans rien y trouver de significatif (mais je n'ai peut être pas tout bien regardé, et il y a peut-être d'autres fichiers que ceux de /var/log/ )
        
        -- vérifier les permissions des /etc/profile, /etc/bashrc, etc. etc. ainsi que /bin/su, et jouer à les modifier pour élargir les droits de lecture/exécution, je l'ai fait aussi, sans noter de grande différence (mais je n'ai peut-être pas exploré toutes les combinaisons)
        
        Pour info :
        
        [root@pc]# ll /etc/profile /etc/bashrc /bin/su /bin/login
        -rwsr-sr-x 1 root root 19516 sep 20 2005 /bin/login*
        -rwsr-xr-x 1 root root 20308 aoû 18 2005 /bin/su*
        -rw-r--r-- 1 root root 944 jun 21 09:24 /etc/bashrc
        -rw-r--r-- 1 root root 963 jun 21 09:23 /etc/profile
        
        Par contre, "remplacer par le nécessaire pour capturer les arguments", là si tu peux préciser, je suis aussi preneur. Tu fais allusion à "strace" ?
        
        [^] # Re: recadrage
        
        Posté par Kerro le 25 juin 2020 à 23:46. Évalué à 3. Dernière modification le 25 juin 2020 à 23:47.
        
        "remplacer par le nécessaire pour capturer les arguments", là si tu peux préciser
        
        Utilise strace pour commencer.
        Ensuite tu pourras te lancer dans des trucs chronophages.
        
        EDIT : ok, vu plus bas.
    - [^] # Re: recadrage
      
      Posté par andrias le 24 juin 2020 à 22:47. Évalué à 1.
      
      si, si ça existait en 2006, et même probablement bien avant, à une époque où dans le monde UNIX on donnait aux programmes des noms en rapport avec ce qu'ils faisaient, au lieu de leur donner des noms d'oiseau ou de mammifères comme on est obligé de le faire maintenant vu l'inflation de logiciels en circulation (mais on ne va pas se plaindre :-)
  - [^] # Re: recadrage
    
    Posté par andrias le 24 juin 2020 à 22:41. Évalué à 1.
    
    pourquoi je n'ai pas utilisé "strace" ? tout simplement parce que j'ignorais l'existence de cet outil, n'en ayant jusqu'à présent jamais eu besoin (pour mes développements, gdb me suffisait).
    
    Mais du coup, ça me semble effectivement pertinent de l'utiliser pour mon problème, et vérification faite, j'ai bien un "strace" sur mon système, je tape donc :
    
    $ strace -r su - toto 2>__strace.log
    
    je saisis en aveugle le mot de passe de toto et ….
    
    rien ! le système refuse d'ouvrir un shell à toto et renvoie plein de choses, dont notamment :
    
    write(2, "su: ", 4su: ) = 4
    write(2, "Mot de passe incorrect.", 23Mot de passe incorrect.) = 23
    write(2, "\n", 1
    ) = 1
    exit_group(1) = ?
    Process 13094 detached
    
    ça commence mal, parce que j'ai bien tapé le bon password. Quelque chose a dû m'échapper, ou bien "strace" est lui aussi dans les choux ?
    - [^] # Re: recadrage
      
      Posté par NeoX le 25 juin 2020 à 07:55. Évalué à 2.
      
      et quand tu fais un simple su - toto tu termines bien en utilisateur toto ?
      
      ta commande strace -r su - toto
      
      ne prendrait-elle pas le - et le toto comme paramètre de strace plutot que de su ?
      executant du coup un simple su donc avec le mot de passe de root et non de toto
      
      il faudrait peut-être taper strace -r 'su - toto'
      - [^] # Re: recadrage
        
        Posté par andrias le 25 juin 2020 à 22:13. Évalué à 1.
        
        et quand tu fais un simple su - toto tu termines bien en utilisateur toto ?
        
        oui, bien sûr, avec les fichiers .profile et .bashrc non exécutés
        
        ta commande strace -r su - toto ne prendrait-elle pas le - et le toto comme paramètre de strace plutot que de su ? executant du coup un simple su donc avec le mot de passe de root et non de toto
        
        il faudrait peut-être taper strace -r 'su - toto'
        
        Bien vu, mais … non. J'avais essayé, mais ça ne marche pas : strace prend "su - toto" comme le nom d'un exécutable et non comme une commande avec ses arguments:
        
        $ strace 'su - toto'
        strace: su - toto: command not found**
        
        Au passage : j'ai une autre machine que je fais tourner sous OpenMandriva version LX 4.0 Nitrogen qui, elle, est récente (téléchargée et installée l'année dernière). Je viens d'y ajouter strace (absent dans la distribution de base), et j'ai fait le test sur cette autre machine : là aussi "strace su - toto" échoue pour la même raison : mot de passe refusé. Donc, "it's not a bug, it's a feature", je serai curieux d'éclaircir la question (peut-être dans un autre post).
        
        En attendant, le seul moyen que j'ai trouvé jusqu'à présent pour contourner ce problème de mot de passe est de lancer à partir de root (puisque dans ce cas 'su' ne demande pas de saisir le mot de passe) :
        
        # strace -f -o __stracef.root2toto.log su - toto
        
        (avec l'option -f pour que le traçage continue après le fork qui transfère le contrôle de 'su' à 'bash')
        
        Pas facile de s'y retrouver, le fichier de log fait dans les 10000 lignes, et je sèche un peu. Je trouve quand même des trucs du genre :
        …
        write (1, "lancement de /etc/profile\n", 26) = 26
        …
        write (1, "lancement de /etc/bashrc\n", 25) = 25
        …
        ce qui signifie que sous strace lancé par root, le "su - toto" fonctionne correctement et qu'une fois lancé, bash lit les fichiers de démarrage /etc/profile et /etc/bashrc, mais pas les fichiers ~toto/.profile ou ~toto/.bashrc
        
        Là, je fatigue un peu, je vais laisser un peu décanter les choses. Ce que je retiens, c'est que STRACE est vraiment un outil intéressant, mais pas parfait puisque la commande "su - toto" ne se comporte pas pareil selon qu'elle est lancée directement ou via STRACE. Hmmm!…
        
        [^] # Re: recadrage
        
        Posté par NeoX le 26 juin 2020 à 11:00. Évalué à 3.
        
        En attendant, le seul moyen que j'ai trouvé jusqu'à présent pour contourner ce problème de mot de passe est de lancer à partir de root (puisque dans ce cas 'su' ne demande pas de saisir le mot de passe) :
        
        le mode d'emploi precise qu'il y a un "bug" connu, qui empêche le programme tracé de prendre son SUID,
        
        Extrait de la page de man :
        Programs that use the setuid bit do not have effective user ID privileges while being traced.
        or c'est justement le cas de la commande su, qui passe root le temps de l'execution, ce qui peut expliqué que cela ne fonctionne pas comme attendu en interactif depuis un compte autre que root.
        
        -rw*s*r-xr-x 1 root root 63568 Jan 10 2019 /bin/su
        
        ensuite toujours dans le man, tu trouve l'option -c qui permet de ne lister que certains appels dans ton cas, les open et write pour voir l'ouverture des fichier et les echo sur le terminal