Bugzilla – Bug 695
sudo command hangs, no output is shown
Last modified: 2015-07-17 09:25:50 MDT
Created attachment 447 [details] strace sudo I upgraded from sudo 1.8.6 to 1.8.11 and now the sudo command hangs with no output. I also upgraded to 1.8.12 and 1.8.13 and see the same thing. I'm attaching an strace of just issuing the command "sudo -", but any switch or no switch hangs. It appears the last syscall is where it hangs: "futex(0x7fc5fe8822a0, FUTEX_WAIT_PRIVATE, 2, NULL" As a workaround, I downloaded 1.8.6p7 from the sudo website, compiled from source and I can run that sudo command from the ./src directory of the package, so it would seem all the sudo dependencies are ok and that the issue is in the sudo program itself. OS: Gentoo Linux Kernel: 3.19.1 x86_64 Please let me know if there is any additional info you need to troubleshoot this and I'll get it to you right away.
gcc (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3 glibc 2.19-r1
I just downloaded/compiled and tried to run the sudo command for each major version from 1.8.6 on and the issue starts happening at 1.8.10 and continues through to current version 1.8.13.
Please add the following to /etc/sudo.conf (creating it if it doesn't already exist): Debug sudo /var/log/sudo_debug all@debug Then try running sudo and attach the resulting sudo_debug file.
Also, if you are able to attach to the sudo process with gdb when it is hung a backtrace (bt) would be helpful.
If I run version 1.8.13's sudo with the /etc/sudo.conf debug enabled, nothing is logged to the /var/log/sudo_debug file, but if I run the 1.8.9p5 version of sudo it does create a debug log file so I'm attaching that if it's helpful. I'm not familiar with the gdb command syntax so I'll look that up and get back to you.
Created attachment 448 [details] sudo_debug log
For gdb it should just be a matter of running as root: # gdb /usr/bin/sudo (gdb) attach pid_of_sudo_process Reading symbols from ... (gdb) bt ...
Here's my gdb output: # gdb /usr/bin/sudo GNU gdb (Gentoo 7.7.1 p1) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/sudo...(no debugging symbols found)...done. (gdb) quit
I think I may need a debug version of 1.8.13? Is that correct?
Yes, a version with debug symbols will be a whole lot easier.
gdb output: # gdb /usr/bin/sudo GNU gdb (Gentoo 7.7.1 p1) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/sudo...done. (gdb) attach 25997 Attaching to program: /usr/bin/sudo, process 25997 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Reading symbols from /usr/lib64/libjemalloc.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libjemalloc.so.1 Reading symbols from /lib64/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libutil.so.1 Reading symbols from /usr/libexec/sudo/libsudo_util.so.0...done. Loaded symbols for /usr/libexec/sudo/libsudo_util.so.0 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 0x00007f51b4812ee4 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x00007f51b4812ee4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f51b480e76c in _L_lock_541 () from /lib64/libpthread.so.0 #2 0x00007f51b480e590 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f51b51e3d40 in ?? () from /usr/lib64/libjemalloc.so.1 #4 0x00007f51b51e5975 in calloc () from /usr/lib64/libjemalloc.so.1 #5 0x00007f51b4600800 in ?? () from /lib64/libdl.so.2 #6 0x00007f51b4600358 in dlsym () from /lib64/libdl.so.2 #7 0x00007f51b4dd2ab6 in sudo_dso_findsym_v1 (handle=<optimized out>, symbol=<optimized out>) at ./sudo_dso.c:259 #8 0x00007f51b5637320 in getenv_unhooked (name=0x7f51b5202fac "MALLOC_CONF") at ./env_hooks.c:73 #9 0x00007f51b5637432 in getenv (name=0x7f51b5202fac "MALLOC_CONF") at ./env_hooks.c:90 #10 0x00007f51b51e368c in ?? () from /usr/lib64/libjemalloc.so.1 #11 0x00007f51b51e3db1 in ?? () from /usr/lib64/libjemalloc.so.1 #12 0x00007f51b51e2b17 in ?? () from /usr/lib64/libjemalloc.so.1 #13 0x00007f51b541bb6e in ?? () from /lib64/ld-linux-x86-64.so.2 #14 0x00007f51b541bc4b in ?? () from /lib64/ld-linux-x86-64.so.2 #15 0x00007f51b540e42a in ?? () from /lib64/ld-linux-x86-64.so.2 #16 0x0000000000000002 in ?? () #17 0x00007ffc7f0ed645 in ?? () #18 0x00007ffc7f0ed64a in ?? () #19 0x0000000000000000 in ?? () (gdb)
Thanks, that clears thing up. There's a livelock situation being caused by sudo's hooking of the getenv() function. It probably only happens with jemalloc() (and only because dlsym() is allocating memory).
Created attachment 449 [details] Patch to avoid a hang in hooked version of getenv() The attached patch should avoid the hang.
The patch file solved the issue for sudo 1.8.10. So with that I assume you know what needs to be done for each version for 1.8.10 - 1.8.13. Thanks for quickly helping with this issue!
Fixed in sudo 1.8.14, available now.