本系列主要是充分使用ebpf來延時如何定位實際問題，在生產中碰到類似問題也可以採用文中所描述方法。
**就是模擬乙個應用啟動，啟動過程會去讀取配置檔案，如果沒有配置檔案會迴圈一直去讀永不止息，這個是為了演示方便（實際應用會退出並提示相關錯誤的）。
# gcc -g -fno-omit-frame-pointer -o0 server.c -o server
其中引數-fno-omit-frame-pointer,o0表示取消棧和相關**編譯優化。
然後執行./server
發現系統卡主了，用top命令檢視該程序還占用一定的cpu資源。
然後使用pidstat來檢視程序每秒使用者和系統資源情況。
# pidstat -u -p $(pidof server) 121時
34分27秒
uid pid %usr %system %guest %cpu cpu command21時
34分28秒
0 2654 5.13 14.10 0.00 19.23 0 server21時
34分29秒
0 2654 5.13 15.38 0.00 20.51 0 server
其中-u表示顯示cpu使用率，另外從監控資料可以看到cpu使用率是位於核心系統。
既然在核心態，那麼程式肯定呼叫了大量的系統呼叫。使用bcc的syscount工具。
既然在核心態，那麼程式肯定呼叫了大量的系統呼叫。使用bcc的syscount工具。
# ./syscount.py -p $(pidof server)
輸出如下：
tracing syscalls, printing top 10... ctrl+c to quit.
^c[21:44:08]
syscall count
open 52400
nanosleep 52400
看主要是open系統呼叫。
使用opensnoop工具，呼叫如下：
#./opensnoop.py -p $(pidof server)
……2654 server -1 2 /etc/tracing-server-example.conf
……發現做開啟的目的檔案了，返回的錯誤為-1，表示檔案找不到。
至此，問題已非常明確。
愛立信實驗室實習感想（一）
時間過的很快，將近一年過去了，上次寫了一篇 愛立信北航聯合實驗室面試經驗 到現在，我已經成了愛立信實驗室的核心成員，負責實驗室重點專案的管理和開發工作。在這不到一年的時間中，從自身感覺出發，確實成長了很多，也學會了很多。接下來，從幾個方面來說說這一年我的感悟。當然，學生，肯定離不開學習，首先來談談學...
實驗室每日一題 2020 11 24
解壓縮後開啟題目.txt，可以看出裡面是16進製制的資料，而且開頭的504b0304是zip檔案的檔案頭，結尾的ffd9是jpg檔案的檔案尾。再結合題目描述可以知道這串16進製制數最起碼包含了乙個zip檔案和乙個jpg檔案。然後就是寫 把這串16進製制資料轉化為正常檔案 好像直接扔010或者winh...
實驗室每日一題 2020 11 26
用winhex開啟壓縮包，檔案末尾有一串用空格隔開的01字元，用.替換0,用 替換1可得到一串摩斯密碼，解開後得到的字元小寫就是壓縮包密碼。解壓後的在linux中用binwalk分解可得到乙個加密的壓縮包，用winhex開啟 檔案，在檔案末尾有一串base64，解碼後就是壓縮包密碼。解壓後得到的pn...