Файл дескриптор в Linux с примери

Веднъж, на едно интервю ми зададоха въпрос: какво ще направиш, ако откриеш неработеща услуга заради това, че дискът е запълнен?

Разбира се, отговорих, че ще проверя какво заема това място и ако е възможно, ще освобода пространство.
Тогава интервюиращият попита, а какво ако на дяла няма свободно място, но и файлове, които да заемат всичкото пространство, не виждаш?

На това казах, че винаги може да се погледнат отворените файлови дескриптори, например с командата lsof и да разберем коя програма е заела всичкото налично място, а след това можем да действаме в зависимост от обстоятелствата, в зависимост от това дали данните са важни.

Интервюиращият ме прекъсна в последната дума, допълвайки въпроса си: "Да предположим, че данните не ни трябват, това е просто дебъг лог, но приложението не работи, защото не може да запише дебъг"?

"Окей", отговорих аз, "можем да изключим дебъга в конфигурацията на приложението и да го рестартираме".
Интервюиращият възрази: "Не, не можем да рестартираме приложението, в паметта все още съхраняваме важни данни, а към самата услуга са свързани важни клиенти, които не можем да накараме да се преинсталират".

"Добре", казах аз, "ако не можем да рестартираме приложението и данните не са важни, можем просто да изчистим този отворен файл чрез файловия дескриптор, дори ако не го виждаме с командата ls на файловата система".

Интервюиращият остана доволен, а аз не.

Тогава си помислих, защо човекът, проверяващ моите знания, не задълбочава повече? А какво, ако данните всъщност са важни? Какво ако не можем да рестартираме процеса и в същото време този процес записва на файловата система в дял, на който няма свободно място? Какво ако не можем да загубим не само вече записаните данни, но и тези, които този процес записва или се опитва да запише?

Тузик

В началото на кариерата си се опитах да създам малко приложение, в което да се съхранява информация за потребителите. Тогава си мислех как да свържа потребителя с данните му. Например, имам Иванов Иван Иваныч, и той има данни, но как да ги свържа? Мога да посоча директно, че кучето на име "Тузик" принадлежи на него. Но какво, ако той смени името си и вместо Иван стане, например, Оля? В такъв случай нашата Оля Ивановна Иванова вече няма да има куче, а нашият Тузик все още ще принадлежи на несъществуващия Иван. Решението на този проблем дойде с базата данни, която даваше уникален идентификатор (ID) на всеки потребител, и моят Тузик се свързваше с този ID, който всъщност беше просто пореден номер. По този начин собственикът на Тузик имаше ID номер 2, и за определен момент под този ID беше Иван, а след това под същия ID стана Оля. Проблемът на човечеството и животновъдството беше почти решен.

Файлов дескриптор

Проблемът с файла и програмата, работеща с него, е similar на нашето куче и човек. Да предположим, че отворих файла с име ivan.txt и започнах да записвам думата tuzik, но успях да запиша само първата буква "t" в файла, и файлът беше преименуван, например, на olya.txt. Но файлът остана същият, и все още искам да запиша моя Тузик в него. Всеки път при отваряне на файла с системен повик open на какъвто и да е програмен език получавам уникален ID, който ми показва файла, този ID е файловият дескриптор. И съвсем не е важно какво и кой прави с този файл по-нататък, той може да бъде изтрит, може да бъде преименуван, може да бъде променен собственик или да му се отнемат правата за четене и запис, аз все още ще имам достъп до него, защото в момента на отваряне на файла имах права да го чета и/или записвам и успях да започна работа с него, а значит трябва да продължа да го правя.

В Linux библиотеката libc отваря 3 файлови дескриптора за всяко стартирано приложение (процес) с номера 0, 1, 2. Повече информация можете да намерите на линковете man stdio и man stdout

• Файловият дескриптор 0 се нарича STDIN и е асоцииран с въвеждане на данни за приложението
• Файл дескриптор 1 е STDOUT и се използва от приложения за извеждане на данни, например от команди print.
• Файл дескриптор 2 е STDERR и се използва от приложения за извеждане на данни, които съобщават за грешки.

Ако в програмата си отворите някой файл за четене или запис, най-вероятно ще получите първия свободен ID, който ще бъде номер 3.

Списъкът с файлови дескриптори може да се види при всеки процес, ако знаете неговия PID.

Например, ще отворим конзолата с bash и ще видим PID на нашия процес.

[user@localhost ]$ echo $$
15771

Във втората конзола ще стартираме

[user@localhost ]$ ls -lah /proc/15771/fd/
total 0
dr-x------ 2 user user  0 Oct  7 15:42 .
dr-xr-xr-x 9 user user  0 Oct  7 15:42 ..
lrwx------ 1 user user 64 Oct  7 15:42 0 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 1 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 2 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 255 -> /dev/pts/21

Файл дескриптор с номер 255 можете без проблем да игнорирате в рамките на тази статия, той е бил отворен за собствените нужди на bash, а не от линкованата библиотека.

Сега всичките 3 файлови дескриптора са свързани с устройството на псевдотерминал. /dev/pts, но все пак можем да манипулираме с тях, например ще стартираме във втората конзола.

[user@localhost ]$ echo "hello world" > /proc/15771/fd/0

И в първата конзола ще видим.

[user@localhost ]$ hello world

Redirect и Pipe

Можете лесно да преопределите тези 3 файлови дескриптора в всеки процес, включително и в bash, например чрез тръба (pipe), свързваща два процеса, да видим.

[user@localhost ]$ cat /dev/zero | sleep 10000

Можете сами да стартирате тази команда с strace -f и да видите какво се случва вътре, но накратко ще ви разкажа.

Нашият родителски процес bash с PID 15771 анализира нашата команда и разбира колко точно команди искаме да стартираме, в нашия случай те са две: cat и sleep. Bash знае, че трябва да създаде два дъщерни процеса и да ги свърже с една тръба. Следователно, bash ще изисква 2 дъщерни процеса и една тръба.

Преди да създаде дъщерни процеси, bash изпълнява системен повик pipe и получава нови файлови дескриптори на временното буферно пространство на тръбата, но това буферно пространство все още не връзва нашите два дъщерни процеса.

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

PID    command
15771  bash
lrwx------ 1 user user 64 Oct  7 15:42 0 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 1 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 2 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:42 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:42 255 -> /dev/pts/21

След това с помощта на системен повик clone bash създава два потомствени процеса, и трите ни процеса ще изглеждат така:

PID    команда
15771  bash
lrwx------ 1 user user 64 Окт  7 15:42 0 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:42 1 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:42 2 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:42 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:42 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:42 255 -> /dev/pts/21
PID    команда
9004  bash
lrwx------ 1 user user 64 Окт  7 15:57 0 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 1 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 2 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:57 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:57 255 -> /dev/pts/21
PID    команда
9005  bash
lrwx------ 1 user user 64 Окт  7 15:57 0 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 1 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 2 -> /dev/pts/21
lrwx------ 1 user user 64 Окт  7 15:57 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:57 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Окт  7 15:57 255 -> /dev/pts/21

Не забравяйте, че clone клонира процеса заедно с всички файлови дескриптори, затова в родителския и потомствените процеси те ще бъдат еднакви. Задачата на родителския процес с PID 15771 е да следи потомствените процеси, затова той просто чака отговор от тях.

Следователно pipe не му е необходим, и той затваря файловите дескриптори с номера 3 и 4.

В първия потомствен процес bash с PID 9004, със системен повик dup2, променя нашия STDOUT файлов дескриптор с номер 1 на файлов дескриптор, сочещ към pipe, в нашия случай това е номер 3. Така всичко, което първият потомствен процес с PID 9004 ще пише в STDOUT, автоматично ще попада в буфера на pipe.

Във втория потомствен процес с PID 9005 bash променя с помощта на dup2 файловия дескриптор STDIN с номер 0. Сега всичко, което вторият bash с PID 9005 ще чете, ще чете от pipe.

След това в потомствените процеси също така се затварят файловите дескриптори с номера 3 и 4, тъй като те вече не се използват.

Файл дескриптор 255 умишлено игнорирам, той се използва за вътрешни нужди на самия bash и в потомствените процеси също ще бъде затворен.

След това в първия потомствен процес с PID 9004 bash стартира със системен повик exec изпълнимия файл, който указахме в командния ред, в нашия случай това е /usr/bin/cat.

Във втория потомствен процес с PID 9005 bash стартира втория изпълним файл, който указахме, в нашия случай това е /usr/bin/sleep.

Системният повик exec не затваря дескрипторите на файловете, ако не са били отворени с флага O_CLOEXEC по време на извикването на open. В нашия случай след стартиране на изпълнимите файлове всички текущи дескриптори на файловете остават запазени.

Проверяваме в консолата:

[user@localhost ]$ pgrep -P 15771
9004
9005
[user@localhost ]$ ls -lah /proc/15771/fd/
total 0
dr-x------ 2 user user  0 Oct  7 15:42 .
dr-xr-xr-x 9 user user  0 Oct  7 15:42 ..
lrwx------ 1 user user 64 Oct  7 15:42 0 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 1 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 2 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:42 255 -> /dev/pts/21
[user@localhost ]$ ls -lah /proc/9004/fd
total 0
dr-x------ 2 user user  0 Oct  7 15:57 .
dr-xr-xr-x 9 user user  0 Oct  7 15:57 ..
lrwx------ 1 user user 64 Oct  7 15:57 0 -> /dev/pts/21
l-wx------ 1 user user 64 Oct  7 15:57 1 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 2 -> /dev/pts/21
lr-x------ 1 user user 64 Oct  7 15:57 3 -> /dev/zero
[user@localhost ]$ ls -lah /proc/9005/fd
total 0
dr-x------ 2 user user  0 Oct  7 15:57 .
dr-xr-xr-x 9 user user  0 Oct  7 15:57 ..
lr-x------ 1 user user 64 Oct  7 15:57 0 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 1 -> /dev/pts/21
lrwx------ 1 user user 64 Oct  7 15:57 2 -> /dev/pts/21
[user@localhost ]$ ps -up 9004
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user  9004  0.0  0.0 107972   620 pts/21   S+   15:57   0:00 cat /dev/zero
[user@localhost ]$ ps -up 9005
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
user  9005  0.0  0.0 107952   360 pts/21   S+   15:57   0:00 sleep 10000

Както виждате, уникалният номер на нашия pipe съвпада в двата процеса. Така имаме връзка между два различни процеса с един родител.

За тези, които не са запознати със системните повиквания, използвани от bash, горещо препоръчвам да стартирате командите чрез strace и да видите какво се случва вътре, например така:

strace -s 1024 -f bash -c "ls | grep hello"

Нека се върнем към нашия проблем с липсата на място на диска и опитите да запазим данни без да рестартираме процеса. Нека напишем малка програма, която ще записва на диска около 1 мегабайт в секунда. Важно е, ако по някаква причина не успеем да запишем данни на диска, просто да игнорираме това и да опитаме отново да запишем данни след секунда. В примера използвам Python, но можете да използвате и друг език за програмиране.

[user@localhost ]$ cat openforwrite.py 
import datetime
import time

mystr="a"*1024*1024+"n"
with open("123.txt", "w") as f:
    while True:
        try:
            f.write(str(datetime.datetime.now()))
            f.write(mystr)
            f.flush()
            time.sleep(1)
        except:
            pass

Стартираме програмата и виждаме файловите дескриптори.

[user@localhost ]$ python openforwrite.py &
[1] 3762
[user@localhost ]$ ps axuf | grep [o]penforwrite
user  3762  0.0  0.0 128600  5744 pts/22   S+   16:28   0:00  |   _ python openforwrite.py
[user@localhost ]$ ls -la /proc/3762/fd
total 0
dr-x------ 2 user user  0 Oct  7 16:29 .
dr-xr-xr-x 9 user user  0 Oct  7 16:29 ..
lrwx------ 1 user user 64 Oct  7 16:29 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  7 16:29 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  7 16:29 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  7 16:29 3 -> /home/user/123.txt

Както виждаме, имаме трите стандартни файлови дескриптора плюс един, който отворихме. Нека проверим размера на файла:

[user@localhost ]$ ls -lah 123.txt 
-rw-rw-r-- 1 user user 117M Oct  7 16:30 123.txt

данните се записват, пробваме да променим правата на файла:

[user@localhost ]$ sudo chown root: 123.txt
[user@localhost ]$ ls -lah 123.txt 
-rw-rw-r-- 1 root root 168M Oct  7 16:31 123.txt
[user@localhost ]$ ls -lah 123.txt 
-rw-rw-r-- 1 root root 172M Oct  7 16:31 123.txt

Виждаме, че данните все още се записват, въпреки че нашият потребител няма право да записва в файла. Нека опитаме да го изтрием:

[user@localhost ]$ sudo rm 123.txt 
[user@localhost ]$ ls 123.txt
ls: cannot access 123.txt: No such file or directory

Къде се записват данните? И дали изобщо се записват? Проверяваме:

[user@localhost ]$ ls -la /proc/3762/fd
total 0
dr-x------ 2 user user  0 Oct  7 16:29 .
dr-xr-xr-x 9 user user  0 Oct  7 16:29 ..
lrwx------ 1 user user 64 Oct  7 16:29 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  7 16:29 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  7 16:29 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  7 16:29 3 -> /home/user/123.txt (deleted)

Да, нашият файлов дескриптор все още съществува и можем да работим с него така, сякаш е нашият стар файл, можем да го четем, почистваме и копираме.

Нека видим размера на файла:

[user@localhost ]$ lsof | grep 123.txt
python    31083             user    3w      REG                8,5   19923457   2621522 /home/user/123.txt

Размерът на файла е 19923457. Нека опитаме да изчистим файла:

[user@localhost ]$ truncate -s 0 /proc/31083/fd/3
[user@localhost ]$ lsof | grep 123.txt
python    31083             user    3w      REG                8,5  136318390   2621522 /home/user/123.txt

Както виждаме, размерът на файла само нараства и нашият truncate не сработи. Нека се обърнем към документацията за системното повикване open. Ако при отваряне на файла използваме флага O_APPEND, то при всяко записване операционната система проверява размера на файла и записва данните в края на файла, правейки това атомарно. Това позволява на няколко нишки или процеса да записват в един и същи файл. Но в нашия код не използваме този флаг. Можем да видим друг размер на файла в lsof след truncate само ако отворим файла за добавяне, тогава в нашия код вместо

with open("123.txt", "w") as f:

трябва да напишем

with open("123.txt", "a") as f:

Проверяваме с флага „w“

[user@localhost ]$ strace -e trace=open python openforwrite.py 2>&1| grep 123.txt
open("123.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

и с флаг "a"

[user@localhost ]$ strace -e trace=open python openforwrite.py 2>&1 | grep 123.txt
open("123.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

Програмираме вече стартиран процес

Често програмистите използват дебъгери (например GDB) или различни нива на логване в приложението, при създаване и тестване на програма. Linux предлага възможността реално да пишете и променяте вече стартирана програма, например да променяте стойностите на променливи, да задавате точки на прекъсване и т.н.

Връщайки се към оригиналния въпрос за недостатъчното пространство на диска за запис на файл, ще се опитаме да симулираме проблема.

Създаваме файл за нашия дял, който ще монтираме като отделен диск:

[user@localhost ~]$ dd if=/dev/zero of=~/tempfile_for_article.dd bs=1M count=10
10+0 записи в
10+0 записи из
10485760 байта (10 МБ) копирани, 0.00525929 с, 2.0 ГБ/с
[user@localhost ~]$

Създаваме файлова система:

[user@localhost ~]$ mkfs.ext4 ~/tempfile_for_article.dd
mke2fs 1.42.9 (28-Dec-2013)
/home/user/tempfile_for_article.dd не е блоково специално устройство.
Да продължим ли? (y,n) y
...
Записване на суперблокове и информация за счетоводство на файловата система: готово
[user@localhost ~]$

Монтираме файловата система:

[user@localhost ~]$ sudo mount ~/tempfile_for_article.dd /mnt/
[sudo] парола за потребител: 
[user@localhost ~]$ df -h | grep mnt
/dev/loop0      8.7M  172K  7.9M   3% /mnt

Създаваме директория с нашия собственик:

[user@localhost ~]$ sudo mkdir /mnt/logs
[user@localhost ~]$ sudo chown user: /mnt/logs

Отваряме файл само за запис в нашата програма:

with open("/mnt/logs/123.txt", "w") as f:

Стартираме

[user@localhost ]$ python openforwrite.py 

Чакаме няколко секунди

[user@localhost ~]$ df -h | grep mnt
/dev/loop0      8.7M  8.0M     0 100% /mnt

И така, получихме проблема, описан в началото на тази статия. Свободно място 0, заето 100%.

Помним, че спрямо условията на задачата се опитваме да запишем много важни данни, които не могат да се загубят. И същевременно ни трябва да поправим услугата без да рестартираме процеса.

Предположим, че все пак имаме място на диска, но в друга част, например в /home.

Опитваме се "да пренаписваме на летящо" нашия код.

Виждаме PID на нашия процес, който е изял всички места на диска:

[user@localhost ~]$ ps axuf | grep [o]penfor
user 10078 27.2  0.0 128600  5744 pts/22   R+   11:06   0:02  |   _ python openforwrite.py

Свързваме се с процеса през gdb

[user@localhost ~]$ gdb -p 10078
...
(gdb) 

Проверяваме отворените файлови дескриптори:

(gdb) shell ls -lah /proc/10078/fd/
total 0
dr-x------ 2 user user  0 Oct  8 11:06 .
dr-xr-xr-x 9 user user  0 Oct  8 11:06 ..
lrwx------ 1 user user 64 Oct  8 11:09 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:09 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:06 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:09 3 -> /mnt/logs/123.txt

Проверяваме информацията за файловия дескриптор номер 3, който ни интересува

(gdb) shell cat /proc/10078/fdinfo/3
pos:    8189952
flags:  0100001
mnt_id: 482

Помня о том, какой системен повик прави Python (вижте по-горе, където стартирахме strace и намерихме повика open), обработвайки кода ни за отваряне на файл, правим същото сами от името на нашия процес, но битовете O_WRONLY|O_CREAT|O_TRUNC трябва да заменим с числова стойност. За това отваряме изходния код на ядрото, например тук и разглеждаме за какво отговарят флаговете

#define O_WRONLY 00000001
#define O_CREAT 00000100
#define O_TRUNC 00001000

Обединяваме всички стойности в едно, получаваме 00001101

Стартираме повика от gdb

(gdb) call open("/home/user/123.txt", 00001101,0666)
$1 = 4

И така получихме нов дескриптор на файл с номер 4 и ново отворен файл на друг дял, проверяваме:

(gdb) shell ls -lah /proc/10078/fd/
total 0
dr-x------ 2 user user  0 Oct  8 11:06 .
dr-xr-xr-x 9 user user  0 Oct  8 11:06 ..
lrwx------ 1 user user 64 Oct  8 11:09 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:09 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:06 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:09 3 -> /mnt/logs/123.txt
l-wx------ 1 user user 64 Oct  8 11:15 4 -> /home/user/123.txt

Помним примера с pipe — как bash променя файл дескрипторите, и вече научихме системния повик dup2.

Опитваме да заменим един файл дескриптор с друг

(gdb) call dup2(4,3)
$2 = 3

Проверяваме:

(gdb) shell ls -lah /proc/10078/fd/
total 0
dr-x------ 2 user user  0 Oct  8 11:06 .
dr-xr-xr-x 9 user user  0 Oct  8 11:06 ..
lrwx------ 1 user user 64 Oct  8 11:09 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:09 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:06 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:09 3 -> /home/user/123.txt
l-wx------ 1 user user 64 Oct  8 11:15 4 -> /home/user/123.txt

Затваряме файл дескриптор 4, тъй като не ни е нужен:

(gdb) call close (4)
$1 = 0

И излизаме от gdb

(gdb) quit
A debugging session is active.

    Inferior 1 [process 10078] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/python2.7, process 10078

Проверяваме новия файл:

[user@localhost ~]$ ls -lah /home/user/123.txt
-rw-rw-r-- 1 user user 5.1M Oct  8 11:18 /home/user/123.txt
[user@localhost ~]$ ls -lah /home/user/123.txt
-rw-rw-r-- 1 user user 7.1M Oct  8 11:18 /home/user/123.txt

Както виждаме, данните се записват в новия файл, проверяваме стария:

[user@localhost ~]$ ls -lah /mnt/logs/123.txt 
-rw-rw-r-- 1 user user 7.9M Oct  8 11:08 /mnt/logs/123.txt

Данните не са загубени, приложението работи, логовете се записват на ново място.

Нека усложним задачата малко

Да предположим, че данните са важни за нас, но нямаме място на диска в нито един от дяловете и не можем да свържем диск.

Какво можем да направим, е да пренасочим нашите данни, например в pipe, а данните от pipe от своя страна да пренасочим в мрежата чрез някаква програма, например netcat.
Можем да създадем именуван pipe с командата mkfifo. Тя ще създаде псевдофайл в файловата система, дори ако на нея няма свободно място.

Рестартираме приложението и проверяваме:

[user@localhost ]$ python openforwrite.py 
[user@localhost ~]$ ps axuf | grep [o]pen
user  5946 72.9  0.0 128600  5744 pts/22   R+   11:27   0:20  |   _ python openforwrite.py
[user@localhost ~]$ ls -lah /proc/5946/fd
total 0
dr-x------ 2 user user  0 Oct  8 11:27 .
dr-xr-xr-x 9 user user  0 Oct  8 11:27 ..
lrwx------ 1 user user 64 Oct  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:28 3 -> /mnt/logs/123.txt
[user@localhost ~]$ df -h | grep mnt
/dev/loop0      8.7M  8.0M     0 100% /mnt

Няма място на диска, но успешно създаваме именуван pipe там:

[user@localhost ~]$ mkfifo /mnt/logs/megapipe
[user@localhost ~]$ ls -lah /mnt/logs/megapipe 
prw-rw-r-- 1 user user 0 Oct  8 11:28 /mnt/logs/megapipe

Сега трябва да завием всички данни, които попадан в този pipe на друг сървър през мрежата, за което ще използваме същия netcat.

На сървъра remote-server.example.com стартираме

[user@localhost ~]$ nc -l 7777 > 123.txt 

На нашия проблемен сървър стартираме в отделен терминал

[user@localhost ~]$ nc remote-server.example.com 7777 < /mnt/logs/megapipe 

Сега всички данни, които попаднат в pipe, автоматично ще попаднат на stdin в netcat, който ще ги изпрати в мрежата на порт 7777.

Всичко, което ни остава, е да започнем да записваме данните си в този именуван pipe.

Вече имаме стартирано приложение:

[user@localhost ~]$ ps axuf | grep [o]pen
user  5946 99.8  0.0 128600  5744 pts/22   R+   11:27 169:27  |   _ python openforwrite.py
[user@localhost ~]$ ls -lah /proc/5946/fd
total 0
dr-x------ 2 user user  0 Oct  8 11:27 .
dr-xr-xr-x 9 user user  0 Oct  8 11:27 ..
lrwx------ 1 user user 64 Oct  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:28 3 -> /mnt/logs/123.txt

От всички флагове ни трябва само O_WRONLY, тъй като файлът вече съществува и не е необходимо да го изчистваме.

[user@localhost ~]$ gdb -p 5946
...
(gdb) call open("/mnt/logs/megapipe", 00000001,0666)
$1 = 4
(gdb) shell ls -lah /proc/5946/fd
total 0
dr-x------ 2 user user  0 Oct  8 11:27 .
dr-xr-xr-x 9 user user  0 Oct  8 11:27 ..
lrwx------ 1 user user 64 Oct  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:28 3 -> /mnt/logs/123.txt
l-wx------ 1 user user 64 Oct  8 14:20 4 -> /mnt/logs/megapipe
(gdb) call dup2(4,3)
$2 = 3
(gdb) shell ls -lah /proc/5946/fd
total 0
dr-x------ 2 user user  0 Oct  8 11:27 .
dr-xr-xr-x 9 user user  0 Oct  8 11:27 ..
lrwx------ 1 user user 64 Oct  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:28 3 -> /mnt/logs/megapipe
l-wx------ 1 user user 64 Oct  8 14:20 4 -> /mnt/logs/megapipe
(gdb) call close(4)
$3 = 0
(gdb) shell ls -lah /proc/5946/fd
total 0
dr-x------ 2 user user  0 Oct  8 11:27 .
dr-xr-xr-x 9 user user  0 Oct  8 11:27 ..
lrwx------ 1 user user 64 Oct  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:28 3 -> /mnt/logs/megapipe
(gdb) quit
A debugging session is active.

    Inferior 1 [process 5946] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/python2.7, process 5946

Проверяваме отдалечения сървър remote-server.example.com

[user@localhost ~]$ ls -lah 123.txt 
-rw-rw-r-- 1 user user 38M Oct  8 14:21 123.txt

Данните се изпращат, проверяваме проблемния сървър.

[user@localhost ~]$ ls -lah /mnt/logs/
total 7.9M
drwxr-xr-x 2 user user 1.0K Oct  8 11:28 .
drwxr-xr-x 4 root     root     1.0K Oct  8 10:55 ..
-rw-rw-r-- 1 user user 7.9M Oct  8 14:17 123.txt
prw-rw-r-- 1 user user    0 Oct  8 14:22 megapipe

Данните са запазени, проблемът е решен.

Възползвам се от случая да поздравя колегите от компанията Degiro.
Слушайте подкастите на Радио-Т.

На всички добро.

В качеството си на домашно задание предлагам да помислите какво ще бъде в файловите дескриптори на процесите cat и sleep, ако стартирате следната команда:

[user@localhost ~]$ cat /dev/zero 2>/dev/null| sleep 10000

Източник: habr.com