מתאר קובץ בלינוקס עם דוגמאות

פעם אחת, בראיון, שאלו אותי מה הייתם עושים אם תמצאו שירות מקולקל בגלל העובדה שנגמר המקום בדיסק?

כמובן, עניתי שאראה מה המקום הזה עושה ואם אפשר, אנקה את המקום.
ואז המראיין שאל, מה אם אין מקום פנוי במחיצה, אבל אתה גם לא רואה את הקבצים שיתפסו את כל המקום?

על כך אמרתי שתמיד אפשר להסתכל על מתארי קבצים פתוחים, למשל עם הפקודה lsof ולהבין איזו אפליקציה לקחה את כל השטח הפנוי, ואז אפשר לפעול בהתאם לנסיבות, תלוי אם יש צורך בנתונים .

המראיין קטע אותי במילה האחרונה והוסיף לשאלתו: "נניח שאנחנו לא צריכים את הנתונים, זה רק יומן ניפוי באגים, אבל האפליקציה מושבתת כי היא לא יכולה לכתוב את הבאגים"?

"בסדר," עניתי, "נוכל לכבות את ניפוי הבאגים בתצורת האפליקציה ולהפעיל אותה מחדש."
המראיין התנגד: "לא, אנחנו לא יכולים להפעיל מחדש את האפליקציה, עדיין יש לנו נתונים חשובים בזיכרון, ולקוחות חשובים מחוברים לשירות עצמו, שאנחנו לא יכולים להכריח להתחבר מחדש".

"בסדר," אמרתי, "אם לא נוכל להפעיל מחדש את האפליקציה ולא אכפת לנו מהנתונים, נוכל פשוט לנקות את הקובץ הפתוח הזה דרך מתאר הקובץ, גם אם איננו רואים אותו ב-ls פקודה במערכת הקבצים."

המראיין היה מרוצה, אבל אני לא.

ואז חשבתי, למה האדם שבודק את הידע שלי לא חופר לעומק? אבל מה אם הנתונים בכל זאת חשובים? מה אם אנחנו לא יכולים להפעיל מחדש את התהליך, ובמקביל התהליך הזה כותב למערכת הקבצים על מחיצה שאין לה מקום פנוי? מה אם לא נוכל לאבד לא רק את הנתונים שכבר נכתבו, אלא גם את הנתונים שהתהליך הזה כותב או מנסה לכתוב?

טוזיק

בתחילת הקריירה שלי, ניסיתי ליצור אפליקציה קטנה שצריכה לאחסן מידע על משתמשים. ואז חשבתי, איך אני יכול להתאים את המשתמש לנתונים שלו. לדוגמה, יש לי איבנוב איבן איבנוביץ', ויש לו כמה נתונים, אבל איך להתיידד איתם? אני יכול לציין ישירות שהכלב בשם "טוזיק" שייך לאותו איוון. אבל מה אם הוא ישנה את שמו ובמקום איבן יהפוך, למשל, לאוליה? אז יתברר שלאוליה איבנובנה איבנובה שלנו כבר לא יהיה כלב, והטוזיק שלנו עדיין יהיה שייך לאיוון הלא קיים. בסיס הנתונים עזר לפתור את הבעיה הזו, שנתנה לכל משתמש מזהה ייחודי (ID), וה-Tuzik שלי היה קשור למזהה הזה, שלמעשה היה רק ​​מספר סידורי. לפיכך, הבעלים של הטוזיק היה עם מספר תעודת זהות 2, ובשלב מסוים איבן היה בתעודת זהות זו, ואז אוליה הפכה לאותה תעודת זהות. בעיית האנושות וגידול בעלי החיים נפתרה למעשה.

מתאר קובץ

הבעיה של קובץ ותוכנית שעובדים עם הקובץ הזה היא בערך כמו הכלב והאדם שלנו. נניח שפתחתי קובץ בשם ivan.txt והתחלתי לכתוב בו את המילה tuzik, אבל הצלחתי לכתוב רק את האות הראשונה "t" לקובץ, והקובץ הזה שונה על ידי מישהו, למשל, ל-olya.txt. אבל הקובץ זהה ואני עדיין רוצה לכתוב לו את האס שלי. בכל פעם שאתה פותח קובץ עם קריאת מערכת לפתוח בכל שפת תכנות, אני מקבל מזהה ייחודי שמפנה אותי לקובץ, מזהה זה הוא מתאר הקובץ. וזה בכלל לא משנה מה ומי יעשה הלאה עם הקובץ הזה, אפשר למחוק אותו, אפשר לשנות את שמו, הוא יכול לשנות את הבעלים שלו או לקחת ממנו את זכויות הקריאה והכתיבה, עדיין תהיה לי גישה אליו, כי בזמן פתיחת הקובץ היו לי זכויות לקרוא ו/או לכתוב אותו והצלחתי להתחיל לעבוד איתו, מה שאומר שאני חייב להמשיך לעשות זאת.

בלינוקס, ספריית libc פותחת 3 קבצי תיאור עבור כל יישום (תהליך) הפועל, עם המספרים 0,1,2. מידע נוסף תוכל למצוא בקישורים man stdio и גבר מצטיין

• מתאר הקובץ 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

Redirect ו-Pipe

אתה יכול בקלות לעקוף את 3 קבצי התיאור הללו בכל תהליך, כולל ב-bash, למשל, דרך צינור (צינור) המחבר שני תהליכים, ראה

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

אתה יכול להפעיל את הפקודה הזו בעצמך strace -f ולראות מה קורה בפנים, אבל אני אעשה את זה קצר.

תהליך ההורות שלנו עם PID 15771 מנתח את הפקודה שלנו ומבין בדיוק כמה פקודות אנחנו רוצים להפעיל, במקרה שלנו יש שתיים מהן: חתול ושינה. בש יודע שצריך ליצור שני תהליכי ילד, ולמזג אותם לצינור אחד. בסך הכל, 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 dup2s את הקובץ ל-STDIN descriptor number 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) או ברמות שונות של רישום באפליקציה. לינוקס מספקת את היכולת לכתוב ולשנות תוכנית שכבר פועלת, כמו שינוי ערכי משתנים, הגדרת נקודת שבירה וכו' וכו'.

אם נחזור לשאלה המקורית על חוסר מקום בדיסק לכתיבת קובץ, בואו ננסה לדמות את הבעיה.

בואו ניצור קובץ עבור המחיצה שלנו, אותו נטען ככונן נפרד:

[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 עושה (ראה למעלה היכן הרצנו את ה-strace ומצאנו קריאה פתוחה), בזמן עיבוד הקוד שלנו לפתיחת קובץ, אנחנו עושים את אותו הדבר בעצמנו בשם התהליך שלנו, אבל אנחנו צריכים את ה-O_WRONLY|O_CREAT| סיביות O_TRUNC מוחלפות בערך מספרי. לשם כך, פתח את מקורות הליבה, למשל כאן ולראות אילו דגלים אחראים למה

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

אנו משלבים את כל הערכים לאחד, נקבל 00001101

מפעיל את השיחה שלנו מ-gdb

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

אז קיבלנו מתאר קובץ חדש עם מספר 4 וקובץ פתוח חדש במחיצה אחרת, בדוק:

(gdb) shell ls -lah /proc/10078/fd/
total 0
dr-x------ 2 user user  0 Oct  8 11:06 .
dr-xr-xr-x 9 user user  0 Oct  8 11:06 ..
lrwx------ 1 user user 64 Oct  8 11:09 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:09 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:06 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:09 3 -> /mnt/logs/123.txt
l-wx------ 1 user user 64 Oct  8 11:15 4 -> /home/user/123.txt

אנחנו זוכרים את הדוגמה עם pipe - איך bash משנה מתארי קבצים, וכבר למדנו את קריאת המערכת dup2.

מנסה להחליף מתאר קובץ אחד באחר

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

אנו בודקים:

(gdb) shell ls -lah /proc/10078/fd/
total 0
dr-x------ 2 user user  0 Oct  8 11:06 .
dr-xr-xr-x 9 user user  0 Oct  8 11:06 ..
lrwx------ 1 user user 64 Oct  8 11:09 0 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:09 1 -> /dev/pts/22
lrwx------ 1 user user 64 Oct  8 11:06 2 -> /dev/pts/22
l-wx------ 1 user user 64 Oct  8 11:09 3 -> /home/user/123.txt
l-wx------ 1 user user 64 Oct  8 11:15 4 -> /home/user/123.txt

סגור את מתאר קובץ 4, מכיוון שאנו לא צריכים אותו:

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

וצא מ-gdb

(gdb) quit
A debugging session is active.

    Inferior 1 [process 10078] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/bin/python2.7, process 10078

בדיקת הקובץ החדש:

[user@localhost ~]$ ls -lah /home/user/123.txt
-rw-rw-r-- 1 user user 5.1M Oct  8 11:18 /home/user/123.txt
[user@localhost ~]$ ls -lah /home/user/123.txt
-rw-rw-r-- 1 user user 7.1M Oct  8 11:18 /home/user/123.txt

כפי שאתה יכול לראות, הנתונים נכתבים לקובץ חדש, אנו בודקים את הישן:

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

הנתונים לא הולכים לאיבוד, האפליקציה עובדת, היומנים נכתבים למיקום חדש.

בואו נעשה את הדברים קצת יותר קשים

תארו לעצמכם שהנתונים חשובים לנו, אבל אין לנו שטח דיסק באף אחת מהמחיצות ולא נוכל לחבר את הדיסק.

מה שאנחנו יכולים לעשות זה להפנות את הנתונים שלנו למקום כלשהו, ​​למשל, לצינור, ולנתב מחדש את הנתונים מהצינור לרשת דרך תוכנה כלשהי, כמו 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