Filbeskrivare i Linux med exempel

En gång, under en intervju, blev jag frågad vad jag skulle göra om jag upptäckte en icke-fungerande tjänst på grund av att det inte fanns tillräckligt med utrymme på disken.

Självklart svarade jag att jag skulle kontrollera vad som tar upp detta utrymme och om det är möjligt, städa upp utrymmet.
Då frågade intervjuaren, vad händer om det inte finns något ledigt utrymme på partitionen, men du heller inte ser några filer som tar upp allt utrymme?

Till det svarade jag att man alltid kan titta på de öppna filbeskrivarna, till exempel med kommandot lsof, för att förstå vilket program som har tagit allt tillgängligt utrymme, och sedan kan man agera utifrån omständigheterna, beroende på om datan är viktig eller inte.

Intervjuaren avbröt mig på det sista ordet och kompletterade sin fråga: "Anta att datan inte är viktig för oss, det är bara en debug-logg, men applikationen fungerar inte eftersom den inte kan skriva debug-loggen"?

"Okej", svarade jag, "vi kan stänga av debug i applikationens konfiguration och starta om den".
Intervjuaren invände: "Nej, vi kan inte starta om applikationen, vi har fortfarande viktiga data lagrade i minnet och viktiga kunder är kopplade till tjänsten, som vi inte kan tvinga att koppla om."

"Nåväl", sa jag, "om vi inte kan starta om applikationen och datan inte är viktig, så kan vi helt enkelt rensa den här öppna filen genom filbeskrivaren, även om vi inte ser den med ls-kommandot i filsystemet."

Intervjuaren verkade nöjd, men jag gjorde inte det.

Då tänkte jag, varför gräver inte personen som bedömer mina kunskaper djupare? Vad händer om datan faktiskt är viktig? Vad händer om vi inte kan starta om processen, och under tiden skriver denna process till filsystemet på en partition där det inte finns något ledigt utrymme? Vad händer om vi inte kan förlora inte bara redan inspelade data, utan även de data som denna process skriver eller försöker skriva?

Tuzik

I början av min karriär försökte jag skapa en liten applikation där jag behövde lagra information om användare. Jag tänkte då, hur ska jag koppla en användare till deras data? Till exempel, jag har Ivanov Ivan Ivanovich, och han har vissa uppgifter, men hur kopplar jag dem? Jag kan direkt ange att hunden vid namn "Tuzik" tillhör just den Ivan. Men vad händer om han byter namn och plötsligt blir Olya? Då skulle vår Olya Ivanovna Ivanova inte längre ha en hund, medan vår Tuzik fortfarande skulle tillhöra den icke-existerande Ivan. För att lösa detta problem hjälpte en databas, som gav varje användare en unik identifierare (ID), och min Tuzik kopplades till detta ID, som i grund och botten bara var ett ordningsnummer. Således hade Tuziks ägare ID 2, och vid en viss tidpunkt hade detta ID Ivan, och senare blev det Olya. Människans och djurhållningens problem var nästan löst.

Filbeskrivare

Problemet med filen och programmet som arbetar med denna fil är ungefär detsamma som för vår hund och människan. Anta att jag öppnar en fil med namnet ivan.txt och börjar skriva ordet tuzik, men jag hinner bara skriva den första bokstaven "t" i filen, och den här filen blir omdöpt av någon, till exempel till olya.txt. Men filen förblir densamma, och jag vill fortfarande skriva min Tuzik i den. Varje gång jag öppnar filen med ett systemsamtal open i vilket programmeringsspråk som helst får jag en unik ID som pekar på filen, denna ID är filbeskrivaren. Och det spelar ingen roll vad som händer med filen sedan, den kan raderas, den kan omdöpas, ägaren kan bytas ut eller läsrättigheter kan tas bort, jag kommer fortfarande ha tillgång till den, eftersom jag vid tidpunkten för att öppna filen hade rätt att läsa och/eller skriva och jag hann börja arbeta med den, vilket betyder att jag bör fortsätta göra det.

I Linux öppnar libc-biblioteket tre filbeskrivare för varje körd applikation (process), med numren 0, 1, 2. Mer information kan du hitta via länkarna man stdio och man stdout

• Filbeskrivare 0 kallas STDIN och är kopplad till dataingångar i applikationen
• Filbeskrivaren 1 kallas STDOUT och används av applikationer för att skriva ut data, till exempel kommandon som print.
• Filbeskrivaren 2 kallas STDERR och används av applikationer för att skriva ut data som rapporterar om fel.

Om du öppnar en fil för läsning eller skrivning i ditt program får du troligtvis det första lediga ID:t, och det kommer att vara nummer 3.

Listan över filbeskrivare kan ses för vilken process som helst om du vet dess PID.

Till exempel, låt oss öppna en konsol med bash och kolla PID för vår process.

[user@localhost ]$ echo $$
15771

I den andra konsolen kör vi.

[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

Filbeskrivaren med nummer 255 kan du ignorera i denna artikel, den har redan öppnats av bash för sina egna behov, inte av det länkade biblioteket.

Nu är alla 3 filbeskrivare kopplade till en pseudoterminal. /dev/pts, men vi kan fortfarande manipulera dem, till exempel genom att köra i den andra konsolen.

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

Och i den första konsolen ser vi.

[user@localhost ]$ hello world

Redirect och Pipe

Du kan enkelt överskrida dessa 3 filbeskrivare i vilken process som helst, inklusive bash, till exempel via en pipe som kopplar ihop två processer, låt oss se.

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

Du kan själv köra denna kommando med strace -f och se vad som händer inuti, men jag förklarar kort.

Vår föräldraprocess bash med PID 15771 parser vår kommandon och förstår hur många kommandon vi vill köra, i vårt fall är det två: cat och sleep. Bash vet att den behöver skapa två barnprocesser och koppla ihop dem med en pipe. Det totala antalet barnprocesser och en pipe kan vara 2.

Innan bash skapar barnprocesserna gör den ett systemanrop. pipe och får nya filbeskrivare till en temporär buffer pipe, men denna buffer kopplar ännu inte ihop våra två barnprocesser.

För föräldraprocessen ser det ut som om pipen redan finns, medan barnprocesserna ännu inte finns:

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

Därefter använder systemanropet clone bash skapar två barnprocesser, och våra tre processer kommer att se ut så här:

PID    kommando
15771  bash
lrwx------ 1 användare användare 64 7 okt 15:42 0 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:42 1 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:42 2 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:42 3 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:42 4 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:42 255 -> /dev/pts/21
PID    kommando
9004  bash
lrwx------ 1 användare användare 64 7 okt 15:57 0 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 1 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 2 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 3 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:57 4 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:57 255 -> /dev/pts/21
PID    kommando
9005  bash
lrwx------ 1 användare användare 64 7 okt 15:57 0 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 1 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 2 -> /dev/pts/21
lrwx------ 1 användare användare 64 7 okt 15:57 3 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:57 4 -> pipe:[253543032]
lrwx------ 1 användare användare 64 7 okt 15:57 255 -> /dev/pts/21

Vi ska inte glömma att clone klonar processen tillsammans med alla filbeskrivare, så i föräldraprocessen och de underordnade kommer de att vara samma. Uppgiften för föräldraprocessen med PID 15771 är att övervaka de underordnade processerna, så den väntar bara på svar från dem.

Därför behöver den inte pipe, och den stänger filbeskrivarna med nummer 3 och 4.

I den första underordnade processen bash med PID 9004, med systemanropet dup2, ändrar vår STDOUT filbeskrivare med nummer 1 till filbeskrivaren som pekar på pipe, i vårt fall nummer 3. Så, allt som den första underordnade processen med PID 9004 skriver till STDOUT kommer automatiskt att hamna i bufferpippen.

I den andra underordnade processen med PID 9005 ändrar bash med hjälp av dup2 filbeskrivaren STDIN med nummer 0. Nu kommer allt som vår andra bash med PID 9005 läser att läsas från pipen.

Därefter stängs även filbeskrivarna med nummer 3 och 4 i de underordnade processerna, eftersom de inte längre används.

Filbeskrivaren 255 ignorerar jag avsiktligt, den används för bash egna interna behov och kommer även att stängas i de underordnade processerna.

Därefter i den första underordnade processen med PID 9004 startar bash med hjälp av systemanropet exec den exekverbara filen som vi angav i kommandoraden, i vårt fall är det /usr/bin/cat.

I den andra underordnade processen med PID 9005 startar bash den andra exekverbara filen som vi angav, i vårt fall är det /usr/bin/sleep.

Systemanropet exec stänger inte filhandtag om de inte har öppnats med flaggan O_CLOEXEC under anropet open. I vårt fall kommer alla aktuella filhandtag att bevaras efter att de körbara filerna har startats.

Vi kontrollerar i konsolen:

[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

Som ni kan se så är det unika numret på vår pipe samma i båda processerna. Därmed har vi en koppling mellan två olika processer med samma förälder.

För dem som inte är bekanta med systemanropen som bash använder, rekommenderar jag starkt att köra kommandon genom strace för att se vad som händer inuti, till exempel så här:

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

Låt oss återgå till vårt problem med brist på diskutrymme och försök att spara data utan att starta om processen. Vi kommer att skriva ett litet program som skriver till disk ungefär 1 megabyte per sekund. Om vi av någon anledning inte kan skriva data till disken kommer vi helt enkelt att ignorera det och försöka skriva data igen om en sekund. I exemplet använder jag Python, men du kan använda vilket annat programmeringsspråk som helst.

[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

Vi kör programmet och ser på filhandtagen.

[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

Som vi ser har vi våra 3 standard filbeskrivare och ytterligare en som vi har öppnat. Låt oss kontrollera filstorleken:

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

Data skrivs, vi försöker ändra rättigheterna på filen:

[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

Vi ser att data fortfarande skrivs, även om vår användare inte har rätt att skriva till filen. Låt oss försöka radera den:

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

Vart skrivs datan? Och skrivs det alls? Låt oss kontrollera:

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

Ja, vår filbeskrivare existerar fortfarande, och vi kan arbeta med denna filbeskrivare som med vår gamla fil, vi kan läsa den, rensa den och kopiera den.

Låt oss titta på filstorleken:

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

Filstorleken är 19923457. Vi försöker rensa filen:

[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

Som vi ser ökar filstorleken bara och vår truncate fungerade inte. Låt oss titta i dokumentationen för systemanropet. openOm vi använder flaggan O_APPEND när vi öppnar filen, kommer operativsystemet att kontrollera filstorleken vid varje skrivning och skriva data i slutet av filen, och detta görs atomärt. Detta gör att flera trådar eller processer kan skriva till samma fil. Men i vår kod använder vi inte denna flagga. Vi kan se en annan filstorlek i lsof efter truncate endast om vi öppnar filen för tillägg, vilket betyder att vi i vår kod istället för

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

bör vi ha

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

Låt oss kontrollera med "w" flaggan.

[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

och flaggan "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

Programmerar redan körda processer

Ofta använder programmerare debugger (t.ex. GDB) eller olika nivåer av loggning i applikationen vid skapande och testning av program. Linux ger möjligheten att faktiskt skriva och ändra redan körda program, till exempel ändra värden på variabler, sätta breakpoints etc.

Återgår till den ursprungliga frågan om bristen på utrymme på disken för att skriva filen, låt oss försöka simulera problemet.

Låt oss skapa en fil för vår partition, som vi kommer att montera som en separat disk:

[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 ~]$

Skapa ett filsystem:

[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 ~]$

Montera filsystemet:

[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

Skapar en katalog med vår ägare:

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

Öppnar filen endast för skrivning i vårt program:

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

Starta

[user@localhost ]$ python openforwrite.py 

Vänta några sekunder

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

Så vi fick problemet som beskrevs i början av den här artikeln. Fritt utrymme 0, upptaget 100%.

Vi kommer ihåg att vi enligt problemet försöker skriva mycket viktigt data som inte får gå förlorad. Och samtidigt behöver vi reparera tjänsten utan att starta om processen.

Anta att vi faktiskt har utrymme på disken, men på en annan partition, till exempel i /home.

Låt oss försöka "omprogrammera programmet på språng".

Kollar PID för vår process som tagit all plats på disken:

[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

Anslut till processen via gdb

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

Kollar öppna filbeskrivare:

(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

Kollar information om filbeskrivaren med nummer 3, som intresserar oss

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

Med tanke på vilken syscall Python gör (se ovan där vi körde strace och hittar open-anropet), när vi hanterar vår kod för att öppna en fil gör vi detsamma själva å vår process vägnar, men vi behöver ersätta O_WRONLY|O_CREAT|O_TRUNC-bitarna med ett numeriskt värde. För detta öppnar vi kärnans källkod, till exempel ). Ett typiskt exempel på användning: och ser vilka flaggor som ansvarar för vad

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

Vi sammanfogar alla värden till ett, vi får 00001101

Vi kör vår anrop från gdb

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

Så vi fick en ny filbeskrivare med nummer 4 och en ny öppen fil på en annan partition, vi kontrollerar:

(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

Vi minns exemplet med pipe — hur bash ändrar filbeskrivare, och vi har redan lärt oss systemanropet dup2.

Vi försöker byta ut en filbeskrivare mot en annan

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

Kontrollerar:

(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

Vi stänger filbeskrivaren 4 eftersom vi inte behöver den:

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

Och vi lämnar 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

Vi kontrollerar den nya filen:

[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

Som vi ser skriver data till den nya filen, vi kontrollerar den gamla:

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

Ingen data har gått förlorad, applikationen fungerar, loggar skrivs till den nya platsen.

Låt oss komplicera uppgiften något

Tänk dig att data är viktiga för oss, men vi har inget utrymme på disken i någon av partitionerna och vi kan inte koppla in en disk.

Vad vi kan göra är att omdirigera våra data någonstans, till exempel till en pipe, och data från pipen kan vi omdirigera till nätverket via något program, som netcat.
Vi kan skapa en namngiven pipe med kommandot mkfifo. Det skapar en pseudofil i filsystemet, även om det inte finns något ledigt utrymme.

Vi återstartar applikationen och kontrollerar:

[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

Det finns ingen ledig diskutrymme, men vi lyckas skapa en namngiven pipe där:

[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

Nu behöver vi på något sätt omdirigera all data som går in i denna pipe till en annan server över nätverket, för detta passar netcat bra.

På servern remote-server.example.com startar vi

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

På vår problemserver startar vi i en separat terminal

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

Nu kommer all data som går in i pipen automatiskt att skickas till stdin i netcat, som skickar dem till nätverket på port 7777.

Det enda vi har kvar att göra är att börja skriva vår data till denna namngivna pipe.

Vi har redan en igångsatt applikation:

[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

Av alla flaggor behöver vi endast O_WRONLY eftersom filen redan finns och vi behöver inte rensa den.

[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

Vi kontrollerar den fjärrstyrda servern remote-server.example.com

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

Data överförs, vi kontrollerar den problematiska servern

[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

Data har sparats, problemet är löst.

Jag passar på att skicka en hälsning till kollegorna på Degiro.
Lyssna på Radio-T:s podcasts.

Önskar alla gott.

Som en hemläxa föreslår jag att vi funderar på vad som kommer att stå i filbeskrivarna för processerna cat och sleep om vi kör följande kommando:

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

Källa: habr.com