Can I recover a nano process from a previous terminal?

Question

My system crashed while I was in a nano session with unsaved changes.

When I log back in via SSH I see the nano process still running when I do a ps.

davidparks21@devdb1:/opt/frugg_batch$ ps -ef | grep nano
1001     31714 29481  0 18:32 pts/0    00:00:00 nano frugg_batch_processing
1001     31905 31759  0 19:16 pts/1    00:00:00 grep --color=auto nano
davidparks21@devdb1:/opt/frugg_batch$

Is there a way I can bring the nano process back under my control in the new terminal?

Or any way to force it to save remotely (from my new terminal)?

Answer 1

Reading nano man page, and some search, I found:

In some cases nano will try to dump the buffer into an emergency file. This will happen mainly if nano receives a SIGHUP or SIGTERM or runs out of memory. It will write the buffer into a file named nano.save if the buffer didn't have a name already, or will add a ".save" suffix to the current filename. If an emergency file with that name already exists in the current directory, it will add ".save" plus a number (e.g. ".save.1") to the current filename in order to make it unique. In multibuffer mode, nano will write all the open buffers to their respective emergency files.

So you should maybe already have such a file waiting for you, somewhere on your system.

find /likely/path -mtime -1 -print | egrep -i '\.save$|\.save\.[1-90]*$'

(/likely/path being first the place where you launched nano from, then other such "possible" places, then in last resort: / (of course, launch that last find command as root or expect a lot of error output, which you could redirect away using your shell's STDERR redirection)

-mtime -1 says "up to 1 day old", you may want to change the value to -2, or -3, depending on when you edited the file and when you read this.

In the event nano did not yet write such a file, you could try to send it a SIGHUP signal to force it to do so (see: http://en.wikipedia.org/wiki/Unix_signal#POSIX_signals )

And then, run the find again to look for that file...

And in last, last resort, you could play with grepping through /proc/kmem for parts of the text you are looking for, but this will necessitate some precautions to sanitize what it shows you, and could be not trivial. or dd it first into a (as big as your memory) file.

Answer 2

It does work as mentioned by @Oliver Dulac, but in some situations instead dumping the buffer to a file, nano just interpret and keep waiting from a user command.

There are more options without reboot:

pkill -SIGHUP -e nano
pkill -SIGTERM -e nano
pkill -SIGILL -e nano

but the program can choose to ignore those 3 signals above, hence try they in the order above, then check if the file was created, and if it do not work, try SIGKILL (that is sent after SIGTERM):

pkill -SIGKILL -e nano

keep in mind that SIGHUP, SIGTERM, and SIGILL can be caught or ignored by the running program, SIGKILL cannot.

• SIGHUP tell the program that the terminal in which it was running is closed, very common thing via remote commands.
• SIGTERM is the user signal to nicely close a program, but it can be ignored if the program needs something (i.e. should it save the buffer over the file?)
• SIGILL inform the program that it is performing something improper and should be closed, but it is still able to interpret and ignore as above;
• SIGKILL will cause the program to be immediately shut down, without it being able to react.

Answer 3

So, this may not be an option for you, but I just sent a reboot command to the box. When it came back online, Viola- file.py.save was put in the directory.

Answer 4

Here is the simple solution, using the "fg" command to bring a job to the foreground:

To view running jobs type the command "jobs", and then type the command "fg <job_id>" passing the job ID you want to restore.

Example:

>> jobs
   [1]+ nano somefile.txt

>> fg 1
   ( nano session is restored at this point)