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

  • 2
    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, 2012 at 18:32

3 Answers 3


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.

  • Sending a HUP did not make it dump the .save file. However the reboot, like stated by @kevin-rutan bellow, worked!
    – cusco
    Oct 29, 2017 at 15:32
  • The answer by Thiago Conrado details the steps to take if SIGHUP doesn't work.
    – Mark Booth
    Apr 5, 2021 at 10:59

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.

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.

  • 1
    Genius, this just saved my S
    – pgr
    Feb 1, 2018 at 13:40
  • Haleluja! Simple but spot on. In my case nano created a .swp file - tried opening and recovering it in vim - didn't work. Now with Kevins solution - when the system shuts down, nano creates a copy of the file that it has openend, and saves it to disk with .save appended to the filename. I was wrting a huge batch file, which I normally never do, so didn't exercise my save routine... May 14, 2019 at 13:44
  • 4
    A complete reboot not needed. Just kill the process. ps aux | grep nano to get the PID, then kill <PID> it should create the *.save file for you. That way you don't interrupt any other services that may be running.
    – Jim
    Oct 8, 2019 at 18:24
  • This is a rather drastic solution, the answer by Thiago Conrado details the steps to take if SIGHUP doesn't work.
    – Mark Booth
    Apr 5, 2021 at 10:59
  • @kevin-rutan & @jim thanks a lot! I was testing Midnight Commander which uses Ctrl+O key binding which clashes with nano save file keybinding. As I was trying to save my nano document, MC stole the shortcut and crashed the nano session. But the PID was still running in the same terminal. I just did not see the contents. There was no .save file, only .swp, but that did not help. So I did what you suggested killl <PID> and the .save file was created. Perfect, thx again.
    – Paloha
    May 17, 2022 at 18:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .