Дескриптор датотеке у Линуку са примерима

Једном, током интервјуа, питали су ме шта ћете учинити ако установите да сервис не ради због чињенице да је на диску понестало простора?

Наравно, одговорио сам да ћу видети шта све заузима ово место и, ако је могуће, очистићу то место.
Затим је анкетар питао, шта ако на партицији нема слободног простора, али не видите ни датотеке које би заузеле сав простор?

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

Анкетар ме је прекинуо на последњој речи, додајући на своје питање: „Претпоставимо да нам не требају подаци, то је само дневник отклањања грешака, али апликација не ради јер не може да напише отклањање грешака“?

„У реду“, одговорио сам, „можемо да искључимо отклањање грешака у конфигурацији апликације и поново је покренемо.“
Анкетар је приговорио: „Не, не можемо поново покренути апликацију, још увек имамо важне податке ускладиштене у меморији, а важни клијенти су повезани на саму услугу, коју не можемо натерати да се поново повеже.

„У реду“, рекао сам, „ако не можемо поново да покренемо апликацију и подаци нам нису важни, онда можемо једноставно да обришемо ову отворену датотеку кроз дескриптор датотеке, чак и ако је не видимо у команди лс на систему датотека."

Анкетар је био задовољан, али ја нисам.

Онда сам помислио, зашто особа која тестира моје знање не копа дубље? Али шта ако су подаци ипак важни? Шта ако не можемо поново покренути процес, а процес уписује у систем датотека на партицији која нема слободног простора? Шта ако не можемо изгубити не само податке који су већ написани, већ и податке које овај процес уписује или покушава да запише?

Тузик

На почетку своје каријере, покушао сам да направим малу апликацију која је требала да чува корисничке податке. А онда сам помислио, како да повежем корисника са његовим подацима. На пример, имам Иванова Ивана Ивановича, и он има неке информације, али како да се спријатељим са њима? Могу директно да истакнем да пас по имену Тузик припада управо овом Ивану. Али шта ако промени име и уместо Иван постане, на пример, Оља? Тада ће се испоставити да наша Оља Ивановна Иванова више неће имати пса, а наш Тузик ће и даље припадати непостојећем Ивану. База података која је сваком кориснику давала јединствени идентификатор (ИД) помогла је у решавању овог проблема, а мој Тузик је био везан за овај ИД, који је, у ствари, био само серијски број. Дакле, власник тузика је имао матични број 2, а у неком тренутку под овом личном картом је био и Иван, а онда је Оља постала под истом. Проблем човечности и сточарства је практично решен.

Дескриптор датотеке

Проблем датотеке и програма који ради са овом датотеком је приближно исти као код нашег пса и човека. Претпоставимо да сам отворио датотеку под називом иван.ткт и почео да уписујем реч тузик у њу, али сам успео да упишем само прво слово „т“ у датотеку, а ову датотеку је неко преименовао, на пример, у олиа.ткт. Али фајл остаје исти, а ја и даље желим да упишем свог кеца у њега. Сваки пут када се датотека отвори системским позивом часови у било ком програмском језику добијам јединствени ИД који ме упућује на датотеку, овај ИД је дескриптор датотеке. И уопште није битно шта и ко даље ради са овим фајлом, може се обрисати, може се преименовати, променити власник или одузети права на читање и писање, и даље ћу имати приступ на њега, јер сам у тренутку отварања датотеке имао права да је читам и/или уписујем и успео сам да почнем да радим са њом, што значи да морам да наставим са тим.

У Линуку, библиотека либц отвара 3 датотеке дескриптора за сваку покренуту апликацију (процес), нумерисане 0,1,2. Више информација можете пронаћи на линковима ман стдио и ман стдоут

• Дескриптор датотеке 0 се зове СТДИН и повезан је са уносом апликације
• Дескриптор датотеке 1 се зове СТДОУТ и користе га апликације за излаз података, као што су команде за штампање
• Дескриптор датотеке 2 се зове СТДЕРР и користе га апликације за излаз порука о грешци.

Ако у свом програму отворите било коју датотеку за читање или писање, онда ћете највероватније добити први бесплатни ИД и он ће бити број 3.

Листа дескриптора датотека може се видети за било који процес ако знате његов ПИД.

На пример, хајде да отворимо басх конзолу и погледамо ПИД нашег процеса

[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 за потребе овог чланка; отворио га је за своје потребе сам басх, а не повезана библиотека.

Сада су све 3 датотеке дескриптора повезане са псеудо терминалним уређајем /дев/птс, али и даље можемо да манипулишемо њима, на пример, да их покренемо у другој конзоли

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

А у првој конзоли ћемо видети

[user@localhost ]$ hello world

Преусмери и Пипе

Можете лако заобићи ове 3 датотеке дескриптора у било ком процесу, укључујући и басх, на пример кроз цев која повезује два процеса, погледајте

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

Можете сами да покренете ову команду страце -ф и види шта се унутра дешава, али ћу ти укратко рећи.

Наш родитељ басх процес са ПИД 15771 анализира нашу команду и разуме тачно колико команди желимо да покренемо, у нашем случају постоје две: цат и слееп. Басх зна да треба да креира два подређена процеса и да их споји у једну цев. Укупно, басх ће требати 2 подређена процеса и један пипе.

Басх покреће системски позив пре креирања подређених процеса цев и прима нове дескрипторе датотека у привременом баферу цеви, али овај бафер још увек не повезује наша два подређена процеса.

За родитељски процес, изгледа да већ постоји цев, али још увек нема подређених процеса:

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
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

Не заборавите да клон клонира процес заједно са свим дескрипторима датотека, тако да ће они бити исти у надређеном и подређеном процесу. Посао родитељског процеса са ПИД-ом 15771 је да надгледа подређене процесе, тако да једноставно чека одговор деце.

Због тога му није потребна цев и затвара дескрипторе датотека под бројем 3 и 4.

У првом басх процесу са ПИД-ом 9004, системски позив дуп2, мења наш дескриптор СТДОУТ датотеке број 1 у дескриптор фајла који показује на цев, у нашем случају је то број 3. Дакле, све што први дете процес са ПИД 9004 запише у СТДОУТ аутоматски ће завршити у баферу цеви.

У другом подређеном процесу са ПИД 9005, басх користи дуп2 да промени дескриптор датотеке СТДИН број 0. Сада ће све што ће наш други басх са ПИД 9005 прочитати бити прочитано из цеви.

Након тога, дескриптори фајлова под бројевима 3 и 4 се такође затварају у подређеним процесима, пошто се више не користе.

Намерно игноришем дескриптор датотеке 255; користи га за интерне сврхе сам басх и такође ће бити затворен у подређеним процесима.

Затим, у првом подређеном процесу са ПИД-ом 9004, басх почиње да користи системски позив екец извршна датотека коју смо навели у командној линији, у нашем случају је то /уср/бин/цат.

У другом подређеном процесу са ПИД-ом 9005, басх покреће други извршни фајл који смо навели, у нашем случају /уср/бин/слееп.

Екец системски позив не затвара ручке датотека осим ако нису отворени са О_ЦЛОЕКСЕЦ заставицом у време када је отворен позив направљен. У нашем случају, након покретања извршних датотека, сви тренутни дескриптори датотека ће бити сачувани.

Проверите у конзоли:

[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

Као што видите, јединствени број наше цеви је исти у оба процеса. Тако имамо везу између два различита процеса са истим родитељем.

За оне који нису упознати са системским позивима које басх користи, топло препоручујем да покренете команде кроз страце и видите шта се дешава интерно, на пример овако:

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

Вратимо се на наш проблем понестајања простора на диску и покушаја да сачувамо податке без поновног покретања процеса. Хајде да напишемо мали програм који ће писати приближно 1 мегабајт у секунди на диск. Штавише, ако из неког разлога нисмо били у могућности да запишемо податке на диск, једноставно ћемо то игнорисати и покушати поново да запишемо податке у секунди. У примеру који користим Питхон, можете користити било који други програмски језик.

[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

Као што видите, величина датотеке се само повећава и наш пртљажник није радио. Погледајмо документацију системског позива часови . Ако користимо ознаку О_АППЕНД када отварамо датотеку, онда са сваким писањем, оперативни систем проверава величину датотеке и уписује податке на сам крај датотеке, и то атомски. Ово омогућава вишеструким нитима или процесима да уписују у исту датотеку. Али у нашем коду не користимо ову заставу. Можемо да видимо другачију величину датотеке у лсоф после дебла само ако отворимо датотеку за додатно писање, што значи у нашем коду уместо

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

морамо ставити

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

Провера са „в“ заставицом

[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

Програмирање већ покренутог процеса

Често програмери, приликом креирања и тестирања програма, користе дебагере (на пример ГДБ) или различите нивое пријављивања у апликацију. Линук пружа могућност стварног писања и промене програма који је већ покренут, на пример, промене вредности променљивих, постављање тачке прекида, итд., итд.

Враћајући се на првобитно питање о недовољно простора на диску за писање датотеке, хајде да покушамо да симулирамо проблем.

Хајде да креирамо датотеку за нашу партицију, коју ћемо монтирати као посебан диск:

[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% заузето.

Сетимо се да се према условима задатка трудимо да забележимо веома важне податке који се не могу изгубити. А у исто време, морамо да поправимо услугу без поновног покретања процеса.

Рецимо да још увек имамо простор на диску, али на другој партицији, на пример у /хоме.

Хајде да покушамо да "репрограмирамо у ходу" наш код.

Погледајмо ПИД нашег процеса, који је појео сав простор на диску:

[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

Повежите се са процесом преко гдб-а

[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

Имајући на уму који системски позив Питхон прави (погледајте горе где смо покренули страце и пронашли отворени позив), када обрађујемо наш код за отварање датотеке, ми сами радимо исто у име нашег процеса, али нам је потребан О_ВРОНЛИ|О_ЦРЕАТ| О_ТРУНЦ битови се замењују нумеричком вредношћу. Да бисте то урадили, отворите изворе језгра, на пример овде и погледај које су заставе за шта одговорне

#дефине О_ВРОНЛИ 00000001
#дефине О_ЦРЕАТ 00000100
#дефине О_ТРУНЦ 00001000

Комбинујемо све вредности у једну, добијамо 00001101

Покрећемо позив из гдб-а

(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

Сетимо се примера са пипе – како басх мења дескрипторе фајлова, а већ смо научили системски позив дуп2.

Покушавамо да заменимо један дескриптор датотеке другим

(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) 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

Подаци се не губе, апликација ради, дневници се уписују на нову локацију.

Хајде да мало закомпликујемо задатак

Замислимо да су нам подаци важни, али немамо простора на диску ни на једној партицији и не можемо да повежемо диск.

Оно што можемо да урадимо је да преусмеримо своје податке негде, на пример на цев, и заузврат преусмеримо податке из цеви у мрежу преко неког програма, на пример нетцат.
Можемо креирати именовану цев са командом мкфифо. Он ће креирати псеудо датотеку на систему датотека чак и ако на њој нема слободног простора.

Поново покрените апликацију и проверите:

[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

Сада морамо некако да умотамо све податке који иду у ову цев на други сервер преко мреже; исти нетцат је погодан за ово.

На серверу ремоте-сервер.екампле.цом покрећемо

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

На нашем проблематичном серверу покрећемо у посебном терминалу

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

Сада ће сви подаци који заврше у цеви аутоматски ићи у стдин у нетцат-у, који ће их послати у мрежу на порту 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

Од свих заставица, потребно нам је само О_ВРОНЛИ пошто датотека већ постоји и не морамо да је обришемо

[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

Провера удаљеног сервера ремоте-сервер.екампле.цом

[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

Подаци су сачувани, проблем је решен.

Користим ову прилику да поздравим моје колеге из Дегира.
Слушајте Радио-Т подцасте.

Све у реду.

Као домаћи задатак, предлажем вам да размислите о томе шта ће бити у процесу дескриптори датотека цат и слееп ако покренете следећу команду:

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

Извор: ввв.хабр.цом