I was running gdb over an SSH shell. After a while the shell disconnected due to being idle. On reconnecting I see the gdb instance still running.
How do I take control of the running gdb instance?
Can I start a new gdb instance and take over the session from the running gdb instance?
Note: This is not about keeping the SSH session alive. This is more about taking control of gdb from another shell instance. Regardless of whether it is running from SSH or locally.
You probably can't do anything with the gdb that is already running. It probably no longer has a controlling tty at all. What you probably want to do is kill it and then start a new gdb process, but do it inside a program like tmux or screen. If you do that, then if/when you get disconnected you can easily reattach to the tmux/screen session any time. Just check out the manual for those programs. They do pretty much the same thing. I think tmux is a little more powerful.
Related
This question sounds very stupid to me, but if this is somehow possible it would be really helpful.
My application is crashing and I need to debug it. And I run this application in another computer, via SSH (it's an HTTP server). If I could leave a terminal running the application over GDB and SSH all the time, I'd be able to find the bugs. But I don't have a free computer to do that. What can I do? Is there a way to start GDB with nohup(1) plus &> and stuff like that, so I can see GDB output (where command, for example) later?
A classical Unix program called screen is your friend (or its competitor tmux). It allows to keep a virtual console open across multiple logins:
screen
starts such a session; using you can detach from that; using
screen -r
you can reconnect to it later.
However, you don't even need that; just make your program leave a core dump when it crashes; ulimit -c unlimited says "every program that crashes leaves a core dump"; you can then just open the core dump using gdb later on, and everything will be as if you ran the program inside gdb when it crashed.
gdb core.123456
I'm currently working on an automation script that connects users via telnet to different ports (for different command interpreters) on an embedded system. Since the amount of available memory is pretty low on the system, the number of telnet sessions is limited. If a user doesn't close the telnet session normally, the server-side session will just hang and use up an available telnet session. Is there a way in tcl/expect to send commands/execute a procedure before an xterm window closes?
I did some googling, at it turns out expect supports the trap command which allows to run a script when a certain Unix signal is sent to the process hosting the interpreter.
It appears you have to trap SIGHUP but may be you'll also need to trap SIGTERM and/or SIGQUIT. man 7 signal — if on a Linux-based OS — for more info (on a different OS flavor the manual page section may be different).
We have about 40 computers running identical hardware and software. They all run Ubuntu 11.10. They all have just one user account to log in. The .profile file is set up to launch a daemon process. The code for the daemon is written in C.
Once in a few weeks, we get a report that the daemon is no longer running. This does not happen on all computers but just one or two. We cannot reproduce the problem consistently.
Looking at the code, the application quits when it receives either SIGHUP or SIGTERM.
As I understand, SIGHUP is generated when a user logs off. In our case, the user never logs off. I am wondering if it is possible that SIGHUP could have been generated for some other reason. Any other thought would be appreciated.
Well, there are a couple of things to note about SIGHUP. Firstly, its origin is from the concept of a hang-up, i.e. loss of connection to a console over something like a modem. In modern parlance this generally means it has lost its controlling tty. Unless you've taken care to detach from your tty, any program started in a given terminal will receive a SIGHUP when the terminal is closed. See here for details on how to do this in your program. Other options include:
running your program inside screen or tmux
run your program with nohup or some other daemonising framework
The other possibility is something is deliberately sending your process a SIGHUP which by "tradition" is often used to signal a process that it should re-read its configuration.
Signals can be sent using kill utility or kill syscall.
Of course, you can try and find out who is sending that signal or disconnecting your terminals or network connections, but there is simpler practical way to fix your problem.
When code is supposed to run as a daemon, but really isn't (just like yours), there is a wrapper that can turn any program into daemon. Surprise - this wrapper is called daemon! It has lots of options, probably most importantly for you, option to automatically restart your utility should it ever die for any reason.
If this command is not installed on your Ubuntu, just sudo apt-get install daemon, and man daemon to get started.
I'm accessing through ssh to a linux box. I was simply updateing the packages with yum update. I then disconnected but when I connnected again with ssh using the same account I couldn't now if the update process had already finished.
How can I know the status of tasks I've started before disconnecting when I reconnect to the server?
Thanks in advance
Use screen <program>. At this point you can either disconnect or hit CTRL-A, CTRL-D and do other things. You can later re-attach your session to the screen running your program by screen -r.
Specifically if you want to save the state of your shell between ssh sessions you can just run screen and then run your programs.
I have what is probably a very simple terminal related question.
I'm running Ubuntu 8.10 Intrepid Ibex, using Gnome, and I often open a terminal-based
ssh session only to have it dropped at some point later on. Once the session is dropped the
terminal becomes unusable, obviously because the network connection has been dropped.
Is there a way to re-initialize the session, or even revert to a working local terminal?
Under Windows, using putty, when this happens I can right-click and select restart session,
and do not need to open a new terminal, however under linux my lack of understanding on this
subject has lead me to always close the defunct terminal, and restart a new one from scratch.
I'd like to learn a new and useful trick if there's one out there.
Also, I found the following post which is worded very similarly to mine,
Automatically (or more easily) reconnect to a screen session after network interruption
reconnect-to-a-screen-session-after-network-interr
however, as far as I can tell, this is a different topic.
You want to use your SSH escape. By default it's '~', and ~. will terminate your connection.
The question you linked to is about screen, which is useful for resuming your remote session once you use the escape character to kill your local ssh process and reconnect.
First use ~. to disconnect your ssh connection locally. This gets you back to a working local terminal. You could also you another terminal to kill the appropriate ssh command.
In order to keep your remote state you should use screen as previously suggested.
I recently found out about mosh which is a interesting UDP-based resumable shell client. It uses ssh to initialise the connection, and probably needs mosh installed at the server (and UDP access between the client and server), however it can recover from disconnections and IP changes of the client.
To have your local terminal usable again, you can use the reset command.
To run a command in a virtual terminal you can attach/dettach you can use screen or tmux. Typical usage for screen:
$ screen -S somename
screen$ some-console-command
...
^ad
You detach from screen by typing ctrl+a then d
Then you can list the session and attach to it
$ screen -ls
$ screen -dr somename
screen$