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

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

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

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

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

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

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

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

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

Тузик

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

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

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

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

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

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

Пренасочване и канал

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

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

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

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

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

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

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

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

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
PID    command
9004  bash
lrwx------ 1 user user 64 Oct  7 15:57 0 -> /dev/pts/21
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
lrwx------ 1 user user 64 Oct  7 15:57 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 255 -> /dev/pts/21
PID    command
9005  bash
lrwx------ 1 user user 64 Oct  7 15:57 0 -> /dev/pts/21
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
lrwx------ 1 user user 64 Oct  7 15:57 3 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 4 -> pipe:[253543032]
lrwx------ 1 user user 64 Oct  7 15:57 255 -> /dev/pts/21

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

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

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

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

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

Съзнателно пренебрегвам файловия дескриптор 255; той се използва за вътрешни цели от самия bash и също ще бъде затворен в дъщерни процеси.

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

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

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

Проверете в конзолата:

[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

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

За тези, които не са запознати със системните извиквания, които 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

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

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

и със знамето "а".

[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 и намерихме отвореното повикване), когато обработваме нашия код за отваряне на файл, ние правим същото от името на нашия процес, но имаме нужда от O_WRONLY|O_CREAT| O_TRUNC битовете се заменят с числова стойност. За да направите това, отворете например изходния код на ядрото тук и вижте кои флагове за какво отговарят

#define O_ГРЕШНО 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

Не се губят данни, приложението работи, регистрационните файлове се записват на ново място.

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

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

Това, което можем да направим, е да пренасочим данните си някъде, например към тръба, и на свой ред да пренасочим данните от тръба към мрежата чрез някаква програма, например netcat.
Можем да създадем канал с име с командата 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

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

[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

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

На сървъра remote-server.example.com изпълняваме

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

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

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

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

Всичко, което трябва да направим, е да започнем да записваме нашите данни в този именуван канал.

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

[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

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

Използвам възможността да поздравя колегите от Дегиро.
Слушайте подкасти на Radio-T.

Добър за всички.

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

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

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