What do you do when you try to sudo and root’s PATH has gone kerblooey?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP

up vote
5
down vote

favorite

1

I’ve got a feeling something bad just happened to this machine.

faheem@bulldog:/usr/local/src/mercurial$ sudo dpkg -i 
mercurial_3.0-1_amd64.deb mercurial-common_3.0-1_all.deb    
dpkg: warning: 'ldconfig' not found in PATH or not executable 
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable 
dpkg: error: 2 expected programs not found in PATH or not executable 
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
and /sbin

This is an old unmaintained machine I’ve been using for a while.
Assuming it was going to die some day. Looks like this might be the day.
It starting throwing errors a bit earlier, and it looks like someone just
rebooted it.

UPDATE: After running

sudo -s

I checked the value of path

echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/games

So some stuff is missing from here, e.g. sbin, and /usr/sbin.

UPDATE 2:

As it turns out, person or persons unknown deleted the following lines
from /etc/sudoers.

Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Thanks to Anthony for explaining.

share|improve this question

    up vote
    5
    down vote

    favorite

    1

    I’ve got a feeling something bad just happened to this machine.

    faheem@bulldog:/usr/local/src/mercurial$ sudo dpkg -i 
    mercurial_3.0-1_amd64.deb mercurial-common_3.0-1_all.deb    
    dpkg: warning: 'ldconfig' not found in PATH or not executable 
    dpkg: warning: 'start-stop-daemon' not found in PATH or not executable 
    dpkg: error: 2 expected programs not found in PATH or not executable 
    Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
    and /sbin
    

    This is an old unmaintained machine I’ve been using for a while.
    Assuming it was going to die some day. Looks like this might be the day.
    It starting throwing errors a bit earlier, and it looks like someone just
    rebooted it.

    UPDATE: After running

    sudo -s
    

    I checked the value of path

    echo $PATH
    /usr/local/bin:/usr/bin:/bin:/usr/games
    

    So some stuff is missing from here, e.g. sbin, and /usr/sbin.

    UPDATE 2:

    As it turns out, person or persons unknown deleted the following lines
    from /etc/sudoers.

    Defaults        mail_badpass
    Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    

    Thanks to Anthony for explaining.

    share|improve this question

      up vote
      5
      down vote

      favorite

      1

      up vote
      5
      down vote

      favorite

      1
      1

      I’ve got a feeling something bad just happened to this machine.

      faheem@bulldog:/usr/local/src/mercurial$ sudo dpkg -i 
      mercurial_3.0-1_amd64.deb mercurial-common_3.0-1_all.deb    
      dpkg: warning: 'ldconfig' not found in PATH or not executable 
      dpkg: warning: 'start-stop-daemon' not found in PATH or not executable 
      dpkg: error: 2 expected programs not found in PATH or not executable 
      Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
      and /sbin
      

      This is an old unmaintained machine I’ve been using for a while.
      Assuming it was going to die some day. Looks like this might be the day.
      It starting throwing errors a bit earlier, and it looks like someone just
      rebooted it.

      UPDATE: After running

      sudo -s
      

      I checked the value of path

      echo $PATH
      /usr/local/bin:/usr/bin:/bin:/usr/games
      

      So some stuff is missing from here, e.g. sbin, and /usr/sbin.

      UPDATE 2:

      As it turns out, person or persons unknown deleted the following lines
      from /etc/sudoers.

      Defaults        mail_badpass
      Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      

      Thanks to Anthony for explaining.

      share|improve this question

      I’ve got a feeling something bad just happened to this machine.

      faheem@bulldog:/usr/local/src/mercurial$ sudo dpkg -i 
      mercurial_3.0-1_amd64.deb mercurial-common_3.0-1_all.deb    
      dpkg: warning: 'ldconfig' not found in PATH or not executable 
      dpkg: warning: 'start-stop-daemon' not found in PATH or not executable 
      dpkg: error: 2 expected programs not found in PATH or not executable 
      Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin
      and /sbin
      

      This is an old unmaintained machine I’ve been using for a while.
      Assuming it was going to die some day. Looks like this might be the day.
      It starting throwing errors a bit earlier, and it looks like someone just
      rebooted it.

      UPDATE: After running

      sudo -s
      

      I checked the value of path

      echo $PATH
      /usr/local/bin:/usr/bin:/bin:/usr/games
      

      So some stuff is missing from here, e.g. sbin, and /usr/sbin.

      UPDATE 2:

      As it turns out, person or persons unknown deleted the following lines
      from /etc/sudoers.

      Defaults        mail_badpass
      Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      

      Thanks to Anthony for explaining.

      debian sudo path dpkg

      share|improve this question

      share|improve this question

      share|improve this question

      share|improve this question

      edited Jul 26 ’14 at 18:58

      asked Jul 26 ’14 at 18:07

      Faheem Mitha

      22.6k1879134

      22.6k1879134

          1 Answer
          1

          active

          oldest

          votes

          up vote
          10
          down vote

          accepted

          As the ‘Note:’ at the bottom of your sudo dpkg -i output hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn’t the case here.

          An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you’ll be landed at a root shell prompt. If you echo "$PATH", you’ll likely find /sbin and/or /usr/sbin missing.

          sudo’s default behavior is to keep your user’s $PATH variable intact. That default is normally changed by Debian’s default /etc/sudoers, which contains:

          Defaults        env_reset
          ⋮
          Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
          

          If you’re missing the secure_path line, that’d explain the problem.

          Two options are to add that line back (but someone may have removed it because he/she wanted the user path to be carried over, e.g., because it contains extra elements in /opt, for example) or to add /sbin:/usr/sbin to your user’s $PATH.

          share|improve this answer

            Your Answer

            StackExchange.ready(function() {
            var channelOptions = {
            tags: “”.split(” “),
            id: “106”
            };
            initTagRenderer(“”.split(” “), “”.split(” “), channelOptions);

            StackExchange.using(“externalEditor”, function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using(“snippets”, function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: ‘answer’,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: “”,
            imageUploader: {
            brandingHtml: “Powered by u003ca class=”icon-imgur-white” href=”https://imgur.com/”u003eu003c/au003e”,
            contentPolicyHtml: “User contributions licensed under u003ca href=”https://creativecommons.org/licenses/by-sa/3.0/”u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href=”https://stackoverflow.com/legal/content-policy”u003e(content policy)u003c/au003e”,
            allowUrls: true
            },
            onDemand: true,
            discardSelector: “.discard-answer”
            ,immediatelyShowMarkdownHelp:true
            });

            }
            });

            draft saved
            draft discarded

            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f146748%2fwhat-do-you-do-when-you-try-to-sudo-and-roots-path-has-gone-kerblooey%23new-answer’, ‘question_page’);
            }
            );

            Post as a guest

            Required, but never shown

            1 Answer
            1

            active

            oldest

            votes

            1 Answer
            1

            active

            oldest

            votes

            active

            oldest

            votes

            active

            oldest

            votes

            up vote
            10
            down vote

            accepted

            As the ‘Note:’ at the bottom of your sudo dpkg -i output hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn’t the case here.

            An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you’ll be landed at a root shell prompt. If you echo "$PATH", you’ll likely find /sbin and/or /usr/sbin missing.

            sudo’s default behavior is to keep your user’s $PATH variable intact. That default is normally changed by Debian’s default /etc/sudoers, which contains:

            Defaults        env_reset
            ⋮
            Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            

            If you’re missing the secure_path line, that’d explain the problem.

            Two options are to add that line back (but someone may have removed it because he/she wanted the user path to be carried over, e.g., because it contains extra elements in /opt, for example) or to add /sbin:/usr/sbin to your user’s $PATH.

            share|improve this answer

              up vote
              10
              down vote

              accepted

              As the ‘Note:’ at the bottom of your sudo dpkg -i output hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn’t the case here.

              An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you’ll be landed at a root shell prompt. If you echo "$PATH", you’ll likely find /sbin and/or /usr/sbin missing.

              sudo’s default behavior is to keep your user’s $PATH variable intact. That default is normally changed by Debian’s default /etc/sudoers, which contains:

              Defaults        env_reset
              ⋮
              Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
              

              If you’re missing the secure_path line, that’d explain the problem.

              Two options are to add that line back (but someone may have removed it because he/she wanted the user path to be carried over, e.g., because it contains extra elements in /opt, for example) or to add /sbin:/usr/sbin to your user’s $PATH.

              share|improve this answer

                up vote
                10
                down vote

                accepted

                up vote
                10
                down vote

                accepted

                As the ‘Note:’ at the bottom of your sudo dpkg -i output hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn’t the case here.

                An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you’ll be landed at a root shell prompt. If you echo "$PATH", you’ll likely find /sbin and/or /usr/sbin missing.

                sudo’s default behavior is to keep your user’s $PATH variable intact. That default is normally changed by Debian’s default /etc/sudoers, which contains:

                Defaults        env_reset
                ⋮
                Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
                

                If you’re missing the secure_path line, that’d explain the problem.

                Two options are to add that line back (but someone may have removed it because he/she wanted the user path to be carried over, e.g., because it contains extra elements in /opt, for example) or to add /sbin:/usr/sbin to your user’s $PATH.

                share|improve this answer

                As the ‘Note:’ at the bottom of your sudo dpkg -i output hints at, this is usually caused by $PATH being set wrong. One way that happens is when you run dpkg -i without root; but that isn’t the case here.

                An easy way to confirm the path is to run sudo -s, which tells sudo to run a shell instead of some other program. So you’ll be landed at a root shell prompt. If you echo "$PATH", you’ll likely find /sbin and/or /usr/sbin missing.

                sudo’s default behavior is to keep your user’s $PATH variable intact. That default is normally changed by Debian’s default /etc/sudoers, which contains:

                Defaults        env_reset
                ⋮
                Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
                

                If you’re missing the secure_path line, that’d explain the problem.

                Two options are to add that line back (but someone may have removed it because he/she wanted the user path to be carried over, e.g., because it contains extra elements in /opt, for example) or to add /sbin:/usr/sbin to your user’s $PATH.

                share|improve this answer

                share|improve this answer

                share|improve this answer

                edited Nov 29 at 19:12

                answered Jul 26 ’14 at 18:16

                derobert

                71.3k8151210

                71.3k8151210

                    draft saved
                    draft discarded

                    Thanks for contributing an answer to Unix & Linux Stack Exchange!

                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid

                    • Asking for help, clarification, or responding to other answers.
                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.

                    Some of your past answers have not been well-received, and you’re in danger of being blocked from answering.

                    Please pay close attention to the following guidance:

                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid

                    • Asking for help, clarification, or responding to other answers.
                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.

                    draft saved

                    draft discarded

                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin(‘.new-post-login’, ‘https%3a%2f%2funix.stackexchange.com%2fquestions%2f146748%2fwhat-do-you-do-when-you-try-to-sudo-and-roots-path-has-gone-kerblooey%23new-answer’, ‘question_page’);
                    }
                    );

                    Post as a guest

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Required, but never shown

                    Related Post

                    Leave a Reply

                    Your email address will not be published. Required fields are marked *