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

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

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

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

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

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

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

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

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

Тузик

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

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

Проблемът с файла и програмата, която работи с него, е подобен на нашето куче и човек. Да предположим, че съм отворил файла 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    команда
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

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

[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 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00525929 s, 2.0 GB/s
[user@localhost ~]$

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

[user@localhost ~]$ mkfs.ext4 ~/tempfile_for_article.dd
mke2fs 1.42.9 (28-Dec-2013)
/home/user/tempfile_for_article.dd is not a block special device.
Proceed anyway? (y,n) y
...
Writing superblocks and filesystem accounting information: done
[user@localhost ~]$

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

[user@localhost ~]$ sudo mount ~/tempfile_for_article.dd /mnt/
[sudo] password for user: 
[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 Окт  8 11:27 .
dr-xr-xr-x 9 user user  0 Окт  8 11:27 ..
lrwx------ 1 user user 64 Окт  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Окт  8 11:28 3 -> /mnt/logs/123.txt
l-wx------ 1 user user 64 Окт  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 Окт  8 11:27 .
dr-xr-xr-x 9 user user  0 Окт  8 11:27 ..
lrwx------ 1 user user 64 Окт  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Окт  8 11:28 3 -> /mnt/logs/megapipe
l-wx------ 1 user user 64 Окт  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 Окт  8 11:27 .
dr-xr-xr-x 9 user user  0 Окт  8 11:27 ..
lrwx------ 1 user user 64 Окт  8 11:28 0 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:28 1 -> /dev/pts/22
lrwx------ 1 user user 64 Окт  8 11:27 2 -> /dev/pts/22
l-wx------ 1 user user 64 Окт  8 11:28 3 -> /mnt/logs/megapipe
(gdb) quit
Активна е сесия за отстраняване на грешки.

    Нисша 1 [процес 5946] ще бъде отделен.

Да излезете ли наистина? (y или n) y
Отделяне от програмата: /usr/bin/python2.7, процес 5946

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

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

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

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

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

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

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

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

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

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