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

Posté par  . Licence CC By‑SA.
Étiquettes :
3
20
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  . É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  (site Web personnel) . É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  . Évalué à 2. Dernière modification le 22/06/20 à 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  . É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
  • # HS

    Posté par  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . Évalué à 3. Dernière modification le 25/06/20 à 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  . É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  . É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  . É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  . É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  . É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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.