Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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)?

share|improve this question
Incidentally, this question is a fantastic argument in favor of incorporating screen or tmux into your daily workflow. If you'd been using screen, then it would have been as simple as screen -R at login. – Skyhawk Nov 30 '12 at 18:32

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 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: )

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.