6

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

  • 1
    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
7

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 '17 at 15:32
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.

  • 1
    Genius, this just saved my S – pgr Feb 1 '18 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... – Tobias Beuving May 14 at 13:44
  • 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 at 18:24
0

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, but 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 create, and if it do not work, try the same signal as performing reboot (that is sent after SIGTERM)

pkill -SIGKILL -e nano

keep in your mind that those are signals to the program, the ones in the top can be interpreted and ignored by the running program, the last one.

  • SIGHUP tell the program that the terminal in which it was running very common thing via SSH
  • SIGTERM is the user signal to nicely close a program, but it can be ignored if the program needs something (ie. should it save the buffer over the file?)
  • SIGILL inform the program that it is performing something improper and should be closed, but it still able to interpret and ignore as above;
  • SIGKILL is a final warning, the system will kill the program soon, so the program will interpret and try it best

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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