i run my program in background as follows:
nohup ./program -c config.cfg &
So i saw segmentation fault in my program and decided to run my program with gdb. My program has some infinite loops and may take some hours to deal with a segmentation fault error, again.
So i want to run the program on background.
How should i pass the gdb arguments to nohup?
I tried my hand at getting the gdb debugger to run in the background, but it's designed to be an interactive tool. I think what you are looking for here is a screen. A screen allows you to background the entire shell session by creating a virtual terminal.
Create the screen instance:
me#mybox$ screen -S my_screen_name
Then run:
me#mybox$ gdb --args ./program -c config.cfg
Once you are in the screen, Ctrl-A-D will detach the screen so you can go about your business and it will keep running.
To reattach:
me#mybox$ screen -r my_screen_name
Once you are done, type Ctrl-D in the screen to terminate the screen. For more help with screens, see man screen.
Related
I'm new to exploit development and looking for advice.
My question is: how can I keep giving input from one terminal and debug my program on another?
I usually use gdb.debug from pwntools when having graphical interface, but now I can only SSH remote to the machine which runs the binary, which means gdb.debug cannot create a new terminal.
I saw a video of a demonstration doing that technique in VIM. How can I achieve that?
gdb.debug should still work if you're using SSH as long as you set context.terminal to the right value (e.g. tmux).
How to use pwnlib.gdb
Here's a copy and paste of a response to a similar question:
You can use the pwnlib.gdb to interface with gdb.
You can use the gdb.attach() function:
From the docs:
bash = process('bash')
# Attach the debugger
gdb.attach(bash, '''
set follow-fork-mode child
break execve
continue
''')
# Interact with the process
bash.sendline('whoami')
or you can use gdb.debug():
# Create a new process, and stop it at 'main'
io = gdb.debug('bash', '''
# Wait until we hit the main executable's entry point
break _start
continue
# Now set breakpoint on shared library routines
break malloc
break free
continue
''')
# Send a command to Bash
io.sendline("echo hello")
# Interact with the process
io.interactive()
The pwntools template contains code to get you started with debugging with gdb. You can create the pwntools template by running pwn template ./binary_name > template.py. Then you have to add the GDB arg when you run template.py to debug: ./template.py GDB.
If you get [ERROR] Could not find a terminal binary to use., you might need to set context.terminal before you use gdb.
If you're using tmux, the following will automatically open up a gdb debugging session in a new horizontally split window:
context.terminal = ["tmux", "splitw", "-h"]
And to split the screen with the new gdb session window vertically:
context.terminal = ["tmux", "splitw", "-v"]
(To use tmux, install tmux on your machine, and then just type tmux to start it. Then type python template.py GDB.
If none of the above works, then you can always just start your script, use ps aux, find the PID, and then use gdb -p PID to attach to the running process.
Vim Explanation
You don't need to use vim to use pwntools's gdb features like the guy did in the video you linked, but here's an explanation on what he did (vim's also a nice tool regardless):
While editing his pwn script in vim, the guy first executed the following command:
:!./%
: enters command mode in vim
! executes a shell command
% is basically the name of the file you're currently editing in vim
So if your exploit script was named template.py running :!./% in vim would be the same as running ./template.py in your terminal. This just runs the exploit and enters interactive mode.
It's just a way shortcut to execute your script in vim.
Later, the guy also uses :!./% GDB to actually launch the pwntools gdb session. It's the same thing as running python template.py GDB.
I am running my code from the shell(SSH) in google cloud as
python3 mycode.py
If I close the shell, the computation stops. How can I start a computation and then close the shell(Computation takes a long Time:)).....come back later and see how it is doing.
My code keeps printing results after a certain number of iteration.
Well, in general what you can do is run the code in a way where you can detach from the interactive environment. Using a tool such as screen or tmux. However, Google Cloud Shell is not made for running background tasks, and if i recall correctly, it will terminate after an hour.
You might need to provision a virtual machine to run it on instead. I can recommend using tmux. With tmux, it will be as simple as running tmux and then in the new shell running your script python3 mycode.py. You can then detach using ctrl+b d or simply disconnect. When you reconnect you run tmux attach -dto get back to your script.
I will provide you as well the following possibility:
A Bash Builtin command that you could also use is disown. First, run your process/script in the background (using &, or stopping it with ^Z and then restarting with bg):
$ long_operation_command &
[1] 1156
Note that at this point the process is still linked to the session and in case it is closed it will be killed.
You can the process attached to the session check running jobs in the background:
$ jobs
[1]+ Running long_operation_command
Therefore you can run disown in order to detach the processes from the session:
$ disown
You can confirm this checking the result of your script or command logging in again or checking with top the process still running.
Check also this because it could be interesting, i.e. the difference between nohup foo, foo & and $ foo & disown
I am trying to launch a GUI application (rhythmbox) on a Ubuntu. In the following I try to explain the chain of executed files.
# Window manager executes first
~/i3wm_cmd_wrapper.sh Window_Name ~/mount_enc.sh
This wrapper uses gnome-terminal to execute stuff. This enables opening a terminal at startup where users can enter information.
# mount_enc.sh launches the following command in the end
bash ~/launch_in_bg.sh rhythmbox
mount_enc.sh does exactly what it is supposed to do when starting from a normal terminal. But I'd like to start it automatically at startup and rhythmbox should be kept open after the script is done.
# launch_in_bg.sh is just doing what it's supposed to
($PRGRM > /dev/null 2>&1) &
I can not get the gnome-terminal to open rhythmbox for me. Also I think my approach is wrong if I want rhythmbox to keep running after the gnome-terminal finishes executing the mount_enc.sh script. Can anybody think of a better solution?
If you open a program from the console (even in background), the process of the program is a child process of the console process and will terminate when the console process terminates.
To keep the program's process running it has to be detached from the console process. Detaching can be done in multiple ways. Some examples:
nohup rhythmbox &
or
rhythmbox & disown
To suppress output, use redirection as in your script.
I have tried everything to make this work. login scripts, LXDE-pi autostart, cron task #reboot, init.d, and I cannot get my script running with a terminal window running in the foreground so that I can interact with it. I can get it to run but only in background. Is there any way I can get a script that simply runs: "python /home/pi/myscript.py" at startup and leaves the terminal window open with the script running for my keyboard inputs? I would rather not use the /dev/input/event if at all possible. Thanks
Simply running python /home/pi/myscript.py at startup will run your script without any terminal. So there is no window that can be kept open. The behavior you want can be achieved by starting an terminal application and let it execute your script.
e. g. using xterm:
xterm -e "python /home/pi/myscript.py"
or lxterminal:
lxterminal --command "python /home/pi/myscript.py"
I was missing a simple flag.. what I did was edit ~/.config/lxsession/LXDE-pi/autostart with
#lxterminal -e /home/pi/autoscript.sh
and in that file, I added
cd /home/pi/
python -i 2Trackmain.py
I wasn't using the -i flag, so every time I pressed Enter to move through the interactive py script, it exited the terminal, using -i will keep the window open for your interaction. And I only had to add the change directory part b/c the script called other scripts in the same directory.
I've got a program running in a GNOME Terminal, but the screensaver is acting up and won't let me back in with my password. While waiting for a fix for the gnome-screensaver bug, is there some way to see the output (or even take over the process) in a virtual console (Ctrl-Alt-F1) without being able to interact with the GNOME Terminal?
Clarification: The original issue was the screensaver, but the question I'd like answered is how to see the output from a process running in another terminal, after starting the process without any logging to file. I'm guessing it should be possible to set the output device of a process from a different shell? Or is it possible to put a process in another shell into background mode, and get it into the foreground in the current shell? Or even ask GNOME Terminal to redirect or copy the output?
I've had luck in the past killing the screensaver from a virtual console, unlocking X session.
# Get the pid (xscreensaver, gnome-screensaver, etc.)
ps -f -u $(whoami) | grep screensaver
kill -9 12345 # Replace 12345 with the real pid
EDIT: Seems like this has been thought of, and you should use one of these commands, depending on which screensaver program you use:
xscreensaver-command -exit
gnome-screensaver-comand --exit
See the man page for those commands for more details.
Usual way is to pipe the output to a file, like program > program.log
Do tail -f program.log in another tab of Gnome console, and the same in the non-X console.
Alternatively, use tee to duplicate the output in the same console: program | tee program.log
ssh in to the box. kill the screensaver. su to become root and kill -9 if it's really acting up.
Usually Gnome-Terminal displays the output of one vty out of /dev. So just connect your console to that vty.
Launch program with screen.
Open another terminal, launch screen -x and you have two terminals acting like one. Try it, it's fun :)