Опис на датотеки во Linux со примери

Еднаш, во едно интервју, ме прашаа што би направиле ако најдете расипана услуга поради фактот што на дискот му снема простор?

Се разбира, јас одговорив дека ќе видам што прави ова место и, ако е можно, ќе го исчистам местото.
Потоа интервјуерот праша, што ако нема слободен простор на партицијата, но исто така не ги гледате датотеките што би го зазеле целиот простор?

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

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

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

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

Интервјуерот беше задоволен, но јас не.

Тогаш си помислив, зошто личноста што го тестира моето знаење не копа подлабоко? Но, што ако на крајот на краиштата податоците се важни? Што ако не можеме да го рестартираме процесот, а во исто време овој процес запишува во датотечниот систем на партиција која нема слободен простор? Што ако не можеме да ги изгубиме не само податоците што се веќе напишани, туку и податоците што овој процес ги пишува или се обидува да ги напише?

Тузик

На почетокот на мојата кариера се обидував да создадам мала апликација која требаше да складира информации за корисниците. И тогаш помислив, како можам да го усогласам корисникот со неговите податоци. На пример, јас го имам Иванов Иван Иванович, а тој има некои податоци, но како да се дружам со нив? Можам директно да истакнам дека кучето по име „Тузик“ му припаѓа на истиот Иван. Но, што ако го промени своето име и наместо Иван стане, на пример, Оља? Тогаш ќе испадне дека нашата Оља Ивановна Иванова повеќе нема да има куче, а нашиот Тузик сепак ќе му припаѓа на непостоечкиот Иван. Базата на податоци помогна да се реши овој проблем, кој на секој корисник му даде единствен идентификатор (ID), а мојот Tuzik беше врзан за овој ID, кој, всушност, беше само сериски број. Така, сопственикот на тузикот бил со лична карта број 2, а во одреден момент Иван бил под оваа лична карта, а потоа и Оља станала под истата лична карта. Практично беше решен проблемот со човештвото и сточарството.

Опис на датотека

Проблемот со датотека и програма што работи со оваа датотека е приближно ист како и нашето куче и човек. Да претпоставиме дека отворив датотека со име ivan.txt и почнав да го пишувам зборот tuzik во неа, но успеав да ја напишам само првата буква „t“ во датотеката, а оваа датотека беше преименувана од некој, на пример, во olya.txt. Но датотеката е истата и јас сепак сакам да го напишам мојот кец на неа. Секој пат кога ќе отворите датотека со системски повик отвори на кој било програмски јазик, добивам уникатен ID што ме упатува на датотека, овој ID е дескрипторот на датотеката. И воопшто не е важно што и кој ќе прави понатаму со оваа датотека, може да се избрише, да се преименува, да го смени сопственикот или да ги одземе правата за читање и пишување, сепак ќе имам пристап до неа, бидејќи во моментот на отворање на датотеката имав права да ја читам и/или пишувам и успеав да почнам да работам со неа, што значи дека мора да продолжам да го правам тоа.

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

• Описот на датотеката 0 се нарекува STDIN и е поврзан со внесување на апликацијата.
• Описот на датотеката 1 се нарекува STDOUT и се користи од излезни апликации како што се командите за печатење.
• Описот на датотеката 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

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

Можете лесно да ги отфрлите овие 3 датотеки со дескриптори во кој било процес, вклучително и во bash, на пример, преку цевка (цевка) што поврзува два процеси, видете

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

Можете сами да ја извршите оваа команда strace -f и да видиме што се случува внатре, но ќе го накратам.

Нашиот родителски баш процес со PID 15771 ја анализира нашата команда и разбира точно колку команди сакаме да извршиме, во нашиот случај има две од нив: мачка и спиење. Баш знае дека треба да создаде два детски процеси и да ги спои во една цевка. Вкупно, баш ќе има потреба од 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.

Во првиот баш дете процес со PID 9004, системскиот повик dup2, го менува нашиот дескриптор на датотеката STDOUT број 1 во дескриптор на датотека што покажува на цевка, во нашиот случај тоа е број 3. Така, сè што ќе запише првиот дете процес со PID 9004 на STDOUT автоматски ќе падне во баферот на цевката.

Во вториот процес на дете со PID 9005, bash dup2 ја става датотеката во STDIN дескриптор број 0. Сега сè што ќе прочита нашиот втор баш со 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 после багажникот само ако ја отвориме датотеката за пишување, што значи дека во нашиот код, наместо

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) или различни нивоа на најавување во апликацијата. Линукс обезбедува можност за всушност пишување и менување на веќе работи програма, како што се менување на вредностите на променливите, поставување точка на прекин и така натаму и така натаму.

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

Ајде да создадеме датотека за нашата партиција, која ќе ја монтираме како посебен диск:

[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%.

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

Да речеме дека сè уште имаме простор на дискот, но во друга партиција, на пример, во / дома.

Ајде да се обидеме да го „репрограмираме во лет“ нашиот код.

Го гледаме 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 (видете погоре каде се зазедовме и најдовме отворен повик), додека го обработуваме нашиот код за да отвориме датотека, ние самите го правиме истото во име на нашиот процес, но ни треба 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

Се сеќаваме на примерот со цевка - како 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.

Се добро.

Како домашна задача, предлагам да размислите што ќе има во дескрипторите на датотеките на процесот на мачката и спиењето ако ја извршите следнава команда:

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

Извор: www.habr.com