1

I have run into a problem where I accidentally erased the contents of a conf file. I am trying to use the cp and tail recovery process that I saw online but it does not appear to be working. The file is still in memory:

# ps aux | grep 'process'
root     30495  0.0  0.0  23660   728 ?        S     2015   0:17 /usr/local/sbin/file -C /etc/dir/file.cfg

The contents of /proc/pid look as follows:

ls -l /proc/30495/fd/0
lrwx------. 1 root root 64 Mar  7 11:35 /proc/30495/fd/0 -> socket:[1278416]

CP recovery method:

cp /proc/30495/fd/0 recovered.cfg
cp: cannot open `/proc/30495/fd/0' for reading: No such device or address

Tail recovery:

tail -c +0 -f /proc/30495/fd/0 recovered.cfg
tail: cannot open `/proc/30495/fd/0' for reading: No such device or   address
tail: cannot open `recovered.cfg' for reading: No such file or directory

Is there anything else I can do to get the contents of this file out of RAM?

user53029
  • 2,725
  • 8
  • 40
  • 65
  • `/proc/30495/fd/0` is probably a pipe. It's not an open file descriptor to a deleted file that's still on disk. – Andrew Henle Mar 07 '16 at 19:56
  • 1
    @AndrewHenle actually it's a socket. OP, are you sure file descriptor #0 is the one you're looking for? If you were trying to copy something that was a regular file then it would have worked. `No such device of address` is an indication that it doesn't make sense to read that file in that way: it's not a file. – Celada Mar 07 '16 at 19:58
  • 1
    in the `ls` get rid of the `/0` so you see all fd – frostschutz Mar 07 '16 at 20:05
  • There is only a 0,1 and 2 in the FD folder. They all point to sockets and all give me the same error. I was just using 0 as an example. The file has not been deleted, only the contents erased. Is there no way to grab the file contents out of /proc? – user53029 Mar 07 '16 at 20:18
  • Please `cat` for `/proc/pid/fd/{0-n}` that is for all. You should get your contents from anyone. – Thushi Mar 07 '16 at 21:04
  • Which program has the old version of the file in memory? You could try to core dump it and try to get the file contents out of it, but this will be not easy if the file content is fragmented over the program's heap. – mifritscher Mar 07 '16 at 21:05
  • 1
    just because the file name is in the cmdline does not mean the file itself is still in memory. config files are usually parsed once and then closed so it's gone. look at other recovery methods (`strings -w /dev/disk | grep -C 1000 config_setting`) – frostschutz Mar 07 '16 at 21:40
  • @frostschutz what do I use for config_setting? The file name I want to recover? – user53029 Mar 07 '16 at 22:05
  • To second what @mifritscher said: If all else fails, try running `gcore 30495` and look in the resulting `core.30495` file for words in your deleted file. It's possible, if the config file was reasonably short, that its entire contents are sitting in a stdio buffer in the process's address space. – Mark Plotnick Mar 07 '16 at 22:48
  • It's unlikely that the file would be in `fd/0`. File descriptor 0 is the process's standard input, not a file that it opened from the command line. – Barmar Mar 08 '16 at 20:28

1 Answers1

1

The right solution is to recover the file from its last backup.

Copying from /proc/PID/fd/ only works if the process currently has the file open. It can't do anything about a file that the process had open at some point in the past but no longer does. A program has no need to keep its configuration file open: once it's read its configuration, it closes the file. You aren't going to recover anything that way. The file you're attempting to recover is an unrelated file; it's a network socket that the process is listening on, and you can't read data from a socket like this, not that this would do you any good.

gcore 30495 as suggested by Mark Plotnick would dump a memory image of the process in the file core.30495. You could try to sift through that memory image, but don't get your hopes up: there's a good chance that the process has parsed the configuration file and reused whatever memory it stored the file in for other purposes. It's even likely that the whole configuration file was never entirely in memory, only piece by piece and each piece overwrote the previous one.

You can try deleted file recovery tools. If you're going to try that, stop writing to that filesystem immediately: every write you do reduces your chances of recovering anything. But once again don't get your hopes up: finding a text file is a needle in a haystack. If you find something, take care that it could be an old version, and there's often no way to tell.

For the future, remember to make backups. And put your configuration files under version control (and back up the repository).

Community
  • 1
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175