I am getting a segmentation fault from bash when I try to SSH to a remote server (running RHEL 4.4.5-6). After providing my credentials, the SSH client spits back the "Last login: ..." information, and then just hangs.
Out of curiosity, I pressed Ctrl-C and was able to get to a bash prompt. However, it's not the "usual" prompt that I see (it usually has my username, the server hostname, etc).
login as: xxxxxxx
xxxxx#xxxx's password:
Last login: Fri Mar 30 14:33:41 2012 from xxx.xx.xx.xxx
-bash-4.1$ echo $0
-bash
-bash-4.1$
I tried to run /bin/bash from GDB. After a medium-sized wait time, I finally got a SIGSEGV error:
(gdb) run
Starting program: /bin/bash
Program received signal SIGSEGV, Segmentation fault.
0x08067ab5 in yyparse ()
(gdb)
The last (significant) changes that I've made to the system was installing GNU screen (using yum install screen). Screen seemed to hang as well when I tried to start it (I'm assuming because it tried running bash, and got the same segfault).
Edit:
I tried running rpm -V:
-bash-4.1$ rpm -V bash
-bash-4.1$
Here are my .bash* files:
.bashrc:
# .bashrc
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
.bash_profile:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
.bash_logout:
# ~/.bash_logout
.bash_history is quite long. I erased it, tried logging in again, and got the same results.
You're recursively sourcing your .bashrc from inside itself, which in a short test here does indeed lead to a segmentation fault. Removing that part from your .bashrc should hopefully fix the problem.
Related
I was looking for a way to route the output of my shell scripts to syslog, and found this article, which suggests putting the following line at the top of the script:
exec 1> >(logger -s -t $(basename $0)) 2>&1
I've tried this with the following simple script:
#!/bin/bash
exec 1> >(logger -s -t $(basename $0)) 2>&1
echo "testing"
exit 0
When I run this script from the shell, I do indeed get the message in the syslog, but the script doesn't seem to return--in order to continue interacting with the shell, I need to hit Enter or send a SIGINT signal. What's going on here? FWIW, I'm mostly using this to log the results of cron jobs, so in the wild I probably don't need it to work properly in an interactive shell session, but I'm nervous using something I don't really understand in production. I am mostly worried about spawning a bunch of processes that don't terminate cleanly.
I've tested this on Ubuntu 15.10, Ubuntu 16.04, and OSX, all with the same result.
Cutting a long story short: the shell script does exit and so does the logger — there isn't actually a problem — but the output from the logger lead to confusion.
Converting comments into an answer.
Superficially, given the symptoms you describe, what's going on is that Bash isn't exiting until all its child processes exit. You could try exec >/dev/null 2>&1 before exit 0 to see if that stops the logger — basically, the redirection closes its inputs, so it should terminate, allowing the script to exit.
However, when I try your script (bash logtest.sh) on macOS Sierra 10.12.2 (though I'd not expect it to change in earlier versions), the command exits promptly and produces a log message on the terminal like this (I use Osiris JL: as my prompt):
Osiris JL: bash logtest.sh
Osiris JL: Dec 26 12:23:50 logtest.sh[6623] <Notice>: testing
Osiris JL: ps
PID TTY TIME CMD
71792 ttys000 0:00.25 -bash
534 ttys002 0:00.57 -bash
543 ttys003 0:01.71 -bash
558 ttys004 0:00.44 -bash
Osiris JL:
I hit return on the blank line and got the prompt before the ps command.
Note that the message from logger arrived after the prompt.
When I ran bash logtest.sh (where logtest.sh contained your script), the only key I hit was the return to enter the command (which the shell read before running the command). I then got a prompt, the output from logger, and a blank line with the terminal waiting for input. That's normal. The logger was not still running — I could check that in other windows.
Try typing ls instead of just hitting return. The shell is waiting for input. It wrote its prompt, but the logger output confused the on-screen layout. For me, I got:
Osiris JL: bash logtest.sh
Osiris JL: Dec 26 13:28:28 logtest.sh[7133] <Notice>: testing
ls
README.md ix37.sql mq13.c sh11.o
Safe lib mq13.dSYM so-4018-8770
Untracked ll89 oddascevendesc so-4018-8770.c
ci11 ll89.cpp oddascevendesc.c so-4018-8770.dSYM
ci11.c ll89.dSYM oddascevendesc.dSYM sops
ci11.dSYM ll97 rav73 src
data ll97.c rav73.c tf17
doc ll97.dSYM rav73.dSYM tf17.cpp
es.se-36764 logtest.sh rd11 tf17.dSYM
etc mac-clock-get-time rd11.c tf19
fa37.sh mac-clock-get-time.c rd11.dSYM tf19.c
fileswap.sh mac-clock-get-time.dSYM rn53 tf19.dSYM
gm11 makefile rn53.c x-paste.c
gm11.c matrot13 rn53.dSYM xc19
gm11.dSYM matrot13.c sh11 xc19.c
inc matrot13.dSYM sh11.c xc19.dSYM
infile mq13 sh11.dSYM
Osiris JL:
I have been using gdb quite successfully for a while, but I recently upgraded my version of Ubuntu, and now it seems that I can only get gdb to successfully run my program if I run as root. That is,
~ % gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
tcsh: Permission denied.
During startup program exited with code 1.
(gdb)
fails, whereas
~ % sudo gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
Running .tcshrc
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7adada0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb)
works. One clue is that in the first case, the gdb startup doesn't run my .tcshrc file, whereas in the second case it does.
It seems that this is a simple permissions issue, which I must have fixed at one time, because in the past, I have never needed to run gdb as root. After much googling, however, I wasn't able to find what I might have done (if I did in fact do something). One possible fix - set ptrace permissions - didn't seem to work.
Is there something that needs to be done to allow gdb to run programs without root privileges? I know in OSX, gdb has to be codesigned. Is there something similar for Ubuntu/Linux?
here are some ideas for debugging the gdb problem. comments aren't really feasible for such things, so I put them into an answer.
try the -n option to make sure no init file is loaded.
use the echo program instead of sleep 60 to make debugging simpler (the SIGINT thing in your example is probably specific to the sleep program.
run gdb -batch and put the rest into ~/.gdbinit:
file /bin/echo
run
add set verbose on.
don't forget to clean up ~/.gdbinit when done.
I changed my login shell to bash and gdb no longer needs root permission to debug. Here is the latest :
My .gdbinit file:
(bash) ~ % more .gdbinit
show environment SHELL
file /bin/echo
run 'running .gdbinit'
(bash) ~ %
and the results of running gdb :
(bash) ~ % gdb -q -batch
SHELL = /bin/bash
running .gdbinit
[Inferior 1 (process 3174) exited normally]
(bash) ~ %
I still don't understand why tcsh didn't work, though, and am curious to know. So if anyone has a possible explanation, please comment.
This isn't a complete answer, but things are becoming clearer. The tip above was very helpful. I created the following .gdbinit file
show environment SHELL
file /bin/echo
run 'Goodbye'
and the results were interesting. If SHELL=/usr/tcsh, I get a permissions error, i.e.
~ % setenv SHELL /bin/tcsh
~ % gdb -q -batch
SHELL = /bin/tcsh
tcsh: Permission denied.
/home/calhoun/.gdbinit:12: Error in sourced command file:
During startup program exited with code 1.
Unsetting the shell variable works :
~ % unsetenv SHELL
~ % gdb -q -batch
Environment variable "SHELL" not defined.
Goodbye
[Inferior 1 (process 6992) exited normally]
In this case, run uses /bin/sh to expand the argument list. Setting SHELL to /bin/bash or /bin/dash will use those shells to expand the argument list, e.g.
~ % setenv SHELL /bin/bash
~ % gdb -q -batch
SHELL = /bin/bash
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
Goodbye
[Inferior 1 (process 7280) exited normally]
Oddly, the "no loadable sections' error only happens when the shell variable is explicitly set. Another mystery.
Why /bin/tcsh doesn't work is still baffling. In my case, the permissions on /bin/tcsh are
~ % ls -lh /bin/tcsh
lrwxrwxrwx 1 root root 13 Oct 14 2011 /bin/tcsh -> /usr/bin/tcsh
~ % ls -lh /usr/bin/tcsh
-rwxr-xr-x 1 root root 382K Oct 14 2011 /usr/bin/tcsh
The problem could also be something in my .tcshrc file that is causing the shell to crash in this non-interactive mode.
Check if your program has executable privileges.
ls -l .
-rw-r--r-- 1 opt opt 30010 Aug 16 16:13 test
Something like 'test' maybe caused that when you debug it.
I specified Linux in the launch.json file, via the LaunchCompleteCommand...
MS has 3 different ways to specify the CPU... Windows, Linux or OSx
From https://code.visualstudio.com/docs/cpp/launch-json-reference
"launchCompleteCommand": "exec-run",
"linux": {
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb"
},
In my launch.json file, this LaunchCompleteCommand section was pasted in after the setupCommands section.
I faced this issue before, and files from /usr/bin/gdb* didn't have execution permissions. This happened after I have installed peda, pwndbg and gef.
# chmod +x /usr/bin/gdb-*
I had the same problem and the reason was that someone had set the sticky bit in the gdb executable:
cruiz> ls -l /usr/bin/gdb
-rwsr-sr-x 1 root root 4190760 2010-05-05 07:55 /usr/bin/gdb*
I changed it (chmod 755 /usr/bin/gdb) and now it works.
Before:
cruiz> gdb
...
(gdb) shell
csh: Permission denied.
After the change:
cruiz> gdb
(gdb) shell
cruiz>
Per the title, I'm getting the following warning when I try to scp through an ssh tunnel. In my case, I cannot scp directly to foo because port 1234 on device foo is being forwarded to another machine bar on a private network (and bar is the machine that is giving me a tunnel to 192.168.1.23).
$ # -f and -N don't matter and are only to run this example in one terminal
$ ssh -f -N -p 1234 userA#foo -L3333:192.168.1.23:22
$ scp -P 3333 foo.py ubuntu#localhost:
ubuntu#localhost's password:
stty: standard input: Inappropriate ioctl for device
foo.py 100% 1829 1.8KB/s 00:00
Does anyone know why I might be getting this warning about Inappropriate ioctl for device?
I got the exact same problem when I included the following line on my ~/.bashrc:
stty -ixon
The purpose of this line was to allow the use of Ctrl-s in reverse search of bash.
This gmane link has a solution: (original link dead) => Web Archive version of gmane link
'stty' applies to ttys, which you have for interactive login sessions.
.kshrc is executed for all sessions, including ones where stdin isn't
a tty. The solution, other than moving it to your .profile, is to
make execution conditional on it being an interactive shell.
There are several ways to check for interecative shell. The following solves the problem for bash:
[[ $- == *i* ]] && stty -ixon
Got the same issue while executing the script remotely. After many tries didn't get any luck to solve this error. Then got an article to run a shell script through ssh. This was an issue related to ssh, not any other command. ssh -t "command" -t will allocate a pseudo TTY to the ssh and this error won't come.
at the end i created a blank .cshrc file ( for ubuntu 18.04). worked
I'm trying to use bashdb on CentOS 4.1 (unfortunately I can't choose a different/newer OS).
I installed bash 4.2 then bashdb 4.2-0.8. THere were no complaints from configure, make, make checks, or make install: everything looked peachy.
But trying to use bashdb either as 'bash --debugger myscript' or 'bashdb myscript' always gets this error:
[bot#sjbld1 bin]$ bashdb -- putxen.sh
bash debugger, bashdb, release 4.2-0.8
Copyright 2002, 2003, 2004, 2006, 2007, 2008, 2009, 2010, 2011 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
/usr/local/share/bashdb/lib/setshow.sh: line 91: /dev/pts/2: Permission denied
/usr/local/share/bashdb/lib/setshow.sh: line 91: /dev/pts/2: Permission denied
/usr/local/share/bashdb/lib/setshow.sh: line 91: /dev/pts/2: Permission denied
/usr/local/share/bashdb/lib/setshow.sh: line 91: /dev/pts/2: Permission denied
[bot#sjbld1 bin]$
There's no line 91 in setshow.sh, and there's no /dev/pts in a directory listing of /dev.
Any suggestions how to proceed will be very much appreciated. I'm taking on a broken mess of shell script, and I'm not hot at bash (or Linux) and hope for more intimate debugging than set -x and echo statements.
Thanks
For completeness I should have added the bash script I was trying to use as bashdb test, as requested by konsolebox, though the "Permission denied" problem occurs with any code, and is solved by using sudo as suggested by Red Cricket. Here's the script:
[bot#sjcpbrvpxbld1 bin]$ cat putxen.sh
if [ x$1 == x ]
then
echo must have filename as parameter
exit 1
fi
if [ -e $1 ]
then
echo $1 found
else
echo cannot find ./$1
exit 1
fi
FTPTGT=10.10.10.25
DIRTGT=xva
echo ftp upload file to $DIRTGT directory on $FTPTGT
ftp -n $FTPTGT <<EOF
user anonymous pass
hash
bin
cd $DIRTGT
put "$1"
bye
Since programs often have stdout and stderr redirected, bashdb tries to write its output to a tty, unless directed otherwise; bashdb determines the console running the tty command.
Normally you don't need to run bashdb as root. But for reasons that are a mystery here, the user you are running bashdb as, is not able to write to the tty registered to it. That is:
echo hi > $(tty)
will probably give you the same "Permission denied". Probably ls -l $(tty) will tell you what's up there.
However, as suggested in the comments, you can workaround this by running as root such as via sudo: e.g.
sudo bashdb -- putxen.sh
Another workaround is to add your user to the group, e.g. tty that is listed when you run ls -l $(tty).
I have a little problem with a chroot environment and I hope you could help me :)
Here's my story:
1 - I created a user demo (with a home like /home/demo) and I chrooted him thanks to a script /bin/chrootshell which is as following:
#!/bin/bash
exec -c /usr/sbin/chroot /home/$USER /bin/bash --login -i
2 - Usual login authentication are disabled for this user, so I have to use su - demo to be logged as him
Everything works well (like all the chrooted system commands or my java configuration). But each time I become user demo, it seems my .bashrc or /etc/profile are not sourced... And I don't know why.
But if I launch a manual bash it works as you can see here:
root#test:~# su - demo
bash-4.1$ env
PWD=/
SHELL=/bin/chrootshell
SHLVL=1
_=/bin/env
bash-4.1$ bash
bash-4.1$ env
PWD=/
SHLVL=2
SHELL=/bin/chrootshell
PLOP=export variable test
_=/bin/env
As you can see, my $PLOP variable (describes in /.bashrc == /home/demo/.bashrc) is well set in the second bash, but I don't know why
Thanks in advance if you have any clue about my issue :)
edit: What I actually don't understand is why SHELL=/bin/chrootshell ? in my chroot env I declare my demo user with /bin/bash shell
As far as I can tell the behaviour that you are experiencing is bash working as designed.
In short: when bash is started as a login shell (that is what happens when you call bash with --login) it will read .profile but not .bashrc. When bash is started as a non login shell then bash will read .bashrc but not .profile.
Read the bash manual chapter about startup files for more information.
My suggestion to work around this design decision is to create a .bash_profile with the following content:
if [ -f "~/.profile" ]; then
source "~/.profile"
fi
if [ -f "~/.bashrc" ]; then
source "~/.bashrc"
fi
That will make bash read .profile and .bashrc if started as login shell, and read only .bashrc if started as non login shell. Now you can put the stuff which needs to be done once (during login) in .profile, and the stuff which needs to be done everytime in .bashrc.