Чи можливо отримати вміст запущеного скрипта bash з оперативної пам'яті

Я випадково переписав дуже складний баш-скрипт, де я намагався акуратно реалізувати масштабування та нарізки.

Тепер той самий сценарій все ще запущений, але файлу більше немає, питання: Чи можливо сканувати через оперативної пам’яті та знаходити жалобне представлення самого файлу?

Інша проблема полягає в тому, що я не можу знайти файл / dev / mem або / dev / kmem, вже намагався зібрати його за вміст.

До навколишнього середовища: це хостинг для debian / sid machine (vps) на vpsfx.com

корінь @ heisenberg: ~ # ls -a / dev
. kmsg ptyp2 ptyp9 випадковий tty1 tty5 ttyp2 ttyp9 urandom
.. журнал 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
консольний pts ptyp6 ptypd stdout tty2 tty9 ttyp6 ttypd
fd ptyp0 ptyp7 ptype tty tty3 ttyp0 ttyp7 тип
повний ptyp1 ptyp8 ptypf tty0 tty4 ttyp1 ttyp8 ttypf

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

Якщо припустити, що ОП дійсно означало оперативну пам’ять, а не будь-яким можливим способом , і якщо припустити, що процес, в якому виконується скрипт, має нульовий ліміт файлу ядра (що, як правило, є типовим параметром, cat /proc/PID/limits), то вам потрібно приєднатися до процесу і встановити обмеження ядра на достатньо велике значення, щоб включити зображення процесу та використання сигналу ABRT для створення основного файлу, або використовувати такий інструмент, gdbякий може приєднати до процесу та генерувати основне зображення процесу з ОЗУ.

1. Встановити gdb

У деякій оболонці з тим самим правом власності, як і запущений сценарій або root власність:

2. Зробити, ps axщоб знайти ідентифікатор процесу (PID)
3. gdb -p PID

Зауважте, що це зупинить виконання процесу, але не видалить його з таблиці процесів.

4. У gdb видайте команду generate-core-file

gdb має відповісти на щось подібне Saved corefile core.15113, припускаючи, що PID - це 15113.

5. У gdb видайте команду detach

Ваш сценарій буде продовжуватись (відновитись).

6. У gdb видайте команду quit
7. В оболонці бігайте 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:~$ 

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