16

Я случайно переписал очень сложный сценарий bash, в котором я попытался аккуратно реализовать область видимости и потоки.

Теперь тот же сценарий все еще выполняется, но файла больше нет, вопрос: можно ли сканировать через оперативную память и найти строковое представление самого файла?

Другая проблема: я не могу найти файл /dev /mem или /dev /kmem, уже пытался найти его для поиска.

К среде: это хост машины Debian /sid (vps) на vpsfx.com

root@heisenberg:~# ls -a /dev
.        kmsg   ptyp2  ptyp9  random  tty1   tty5   ttyp2  ttyp9  urandom
..       log    ptyp3  ptypa  shm     tty10  tty6   ttyp3  ttypa  xconsole
.udev    null   ptyp4  ptypb  stderr  tty11  tty7   ttyp4  ttypb  zero
char     ptmx   ptyp5  ptypc  stdin   tty12  tty8   ttyp5  ttypc
console  pts    ptyp6  ptypd  stdout  tty2   tty9   ttyp6  ttypd
fd       ptyp0  ptyp7  ptype  tty     tty3   ttyp0  ttyp7  ttype
full     ptyp1  ptyp8  ptypf  tty0    tty4   ttyp1  ttyp8  ttypf

3 ответа3

16

Посмотрите на /proc /$ PID /fd. Там вы должны открыть все файловые дескрипторы процесса, включая сам скрипт. Просто cat $FD > /tmp/yourscript.sh должно быть достаточно для его восстановления.

14

Предполагая, что OP действительно имел в виду оперативную память, а не каким-либо возможным способом, и предполагая, что процесс, в котором выполнялся сценарий, имеет нулевой предел файла ядра (который обычно является настройкой по умолчанию, cat /proc/PID/limits limit), тогда вам нужно присоединить к процессу и либо установить ограничение ядра на достаточно большое значение, чтобы включить образ процесса и использовать сигнал ABRT для генерации файла ядра, либо использовать инструмент, такой как gdb который может подключаться к процессу и генерировать ядро образ процесса из оперативной памяти.

  1. Установить gdb

В некоторых оболочках с тем же владельцем, что и у запущенного скрипта или владельца root:

  1. Сделайте ps ax чтобы найти идентификатор процесса (PID)
  2. gdb -p PID

Обратите внимание, что это остановит выполнение процесса от продолжения, но не удалит его из таблицы процессов.

  1. В gdb введите команду generate-core-file

GDB должен отвечать с чем-то вроде Saved corefile core.15113 , предполагая, что PID 15113.

  1. В gdb введите команду detach

Ваш скрипт продолжит (возобновит) работу.

  1. В gdb введите команду quit
  2. В оболочке запускаем strings core.15113 > my_script.sh

Откройте my_script.sh в каком-то редакторе. Текст вашего скрипта должен находиться в конце файла перед разделом среды. Используйте редактор, чтобы соскрести разделы до и после сценария.

Протестируйте это решение на другом скрипте, прежде чем использовать его в своем призовом скрипте.  YMMV.

Последовательность выглядит так:

yba@tavas:~$ gdb -p 15113
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 15113
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libtinfo.so.5
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007feaf4b4c7be in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) generate-core-file
Saved corefile core.15113
(gdb) detach
Detaching from program: /bin/bash, process 15113
(gdb) quit
yba@tavas:~$ 
0

dd раздел жесткого диска в перекрывающихся чанках и бинарный файл grep для частей скрипта. если вам повезет, запишите эти чанки во временную директорию в оперативной памяти, чтобы они заглянули в нее, чтобы сохранить цикл записи жесткого диска или ssd. нет, это не решение "от оперативной памяти". помните о том, что при чтении байтовых скриптов на диске может использоваться формат кодировки utf-8 (или аналогичный), поэтому параметры grep также должны быть адаптированы.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .