守護進程概述
守護進程，又叫daemon進程(不知怎的，我突然想起來吸血鬼日記中的達蒙了，很好 看的美劇)，是Linux中的後台服務進程。他是一個生存期較長的進程，通常獨立於控制終端並且周期性地執行 某種任務或者等待處理某些發生的事件。守護進程常常在系統引導載入時啟動，在系統關閉時終止。Linux有 很多系統哦服務，大多數服務都是通過守護進程實現的。同時，守護進程還能完成許多系統任務，例如，作業 規劃進程cronf、打印進程lqd等（這裡的結尾字母 d 就是 daemon的意思）。
在Linux中，每一個系統 與用戶進行交流的界面稱為終端，每一個從此終端開始運行的進程都會依附於這個終端，這個終端稱為這些進 程的控制終端，當控制終端關閉時，相應的進程都會自動關閉。但是守護進程卻能夠突破這種限制，它從被執 行開始運轉，直到接收到某種信號或者整個系統關閉時才退出。如果想讓某個進程不因為用戶、終端或者其它 的變化而受到影響，那麼就必須把這個進程變成一個守護進程。可見，守護進程是非常重要的。
編寫 守護進程步驟
編寫守護進程遵循一個特定的流程，下面就說一下守護進程的創建步驟。
1、創 建子進程，父進程退出。
這是編寫守護進程的第一步。由於守護進程是脫離控制終端的，因此，完成 第一步後就會在shell終端造成一種程序已經運行完畢的假象，之後的所有工作都在子進程中完成，而用戶在 shell終端則可以執行其他的命令，從而在形式上做到與控制終端的脫離。
但是，父進程創建了子進程 後退出，此時該子進程不就沒有父進程了嗎？守護進程中確實會出現這麼一個有趣的現象：由於父進程已經先 於子進程退出，就會造成子進程沒有父進程，從而變成一個孤兒進程。在Linux中，每當系統發現一個孤兒進 程時，就會自動由1號進程(也就是 init 進程)收養它，這樣原先的子進程就會變成 init 進程的子進程。其 關鍵代碼如下;
2、在子進程中創建新會話
這個步驟是創建守護進程最重要的一步，雖然實現非常簡單，但意義卻非常重大。在這裡使用 的是系統函數 setsid()，在具體介紹 setsid()之前，先了解以下兩個概念：進程組和會話期。
進程 組。進程組是一個或多個進程的集合。進程組由進程組ID來唯一標識。除了進程號PID之外，進程組ID也是一 個進程的必備屬性。每隔進程組都有一個組長進程，其組長進程的進程號PID等於進程組ID，且該進程組ID不 會因為組長進程的退出而受到影響。(組長沒了，再找個組員來擔任組長呗)
會話期。會話組是一個或 多個進程組的集合。通常，一個會話開始於用戶登錄，終止於用戶退出，在此期間該用戶運行的所有進程都屬 於這個會話期。進程組和會話期之間的關系如圖1所示：
接下來具體介紹 setsid()的相關內 容。
① setsid()函數的作用。setsid()函數用於創建一個新的會話組，並讓執行此函數的進程擔任該 會話組的組長。調用setsid()有以下3個作用：
讓進程擺脫原會話的控制
讓進程擺脫原進程 組的控制
讓進程擺脫原控制終端的控制
那麼，回過頭來想想，在創建守護進程時為什麼要調 用 setsid()函數呢？是這樣的，在創建守護進程的第一步中，調用了fork()函數創建子進程再令父進程退出 。由於在調用 fork()函數時，子進程全盤復制了父進程的會話期、進程組和控制終端等，雖然父進程退出了 ，但原先的會話期、進程組和控制終端等並沒有改變，因此，還不是真正意義上的獨立。而setsid()函數能夠 使進程完全獨立出來，從而脫離所有其他進程的控制。
② setsid函數格式
3、改變當前目錄為根目錄
這一步也是必要的步驟。使用fork()創建的子進程繼承了父進程的當前 工作目錄。由於在進程運行過程中，當前目錄所在的文件系統（如“/mnt/usb”等）是不能卸載的，這對以後 的使用會造成諸多的麻煩（如系統由於某種原因需要進入單用戶模式）。因此，通常的做法是讓“/”作為守 護進程的當前工作目錄，這樣就可以避免上述問題。當然，如有特殊需要，也可以把當前工作目錄換成其他的 路徑，如/tmp。改變工作目錄的常見函數是chdir()。
4、重設文件權限掩碼
文件權限掩碼是指 屏蔽掉文件權限中的對應位。例如，有一個文件權限掩碼是050，它就屏蔽了文件組擁有者的可讀與可執行權 限。由於使用fork()函數新建的子進程繼承了父進程的文件權限掩碼，這就給該子進程使用文件帶來了諸多的 麻煩。因此，把文件權限掩碼設置為0，可以大大增強該守護進程的靈活性。設置文件權限掩碼的函數是 umask()。通常的使用方法為umask(0)。
5、關閉文件描述符
同文件權限掩碼一樣，用fork()函 數新建的子進程會從父進程那裡繼承一些已經打開的文件。這些被打開的文件可能永遠不會被守護進程讀或寫 ，但它們一樣消耗系統資源，而且可能導致所在的文件系統無法被卸載。
事實上，在上面的第2步之後 ，守護進程已經與所屬的控制終端失去了聯系，因此，從終端輸入的字符不可能達到守護進程，守護進程中用 常規方法(如printf())輸出的字符也不可能在終端上顯示出來。所以文件描述符為0,1和2的3個文件（常說的 輸入/輸出和報錯這3個文件）已經失去了存在的價值，也應該被關閉。通常了，按如下方式關閉文件描述符：
有關getdtables()的作用請看博客：
到這裡，一個簡單的守護進程就建立起來了。創建守護 進程的流程圖如圖所示：
基礎實驗
本實驗按照以 上的創建流程建立了一個守護進程，然後讓守護進程每隔10s向日志文件/home/song/tmp/daemon.log 寫入一句話。程序代碼如下，我也上傳到網站，點此下載
我們先看一下 /tmp文件夾下是沒有daemon.log的
下載文件後，使用命令編譯：gcc dameon.c -o daemon
然後執行命令: ./daemon 你可以看 到此時沒有看到有什麼變化
使用命令：ps -ef|grep ./daemon 利用ps中的關鍵字來查看系統當前正在運行的進程中，有沒有咱們的daemon進程
可以看到咱們的守護進程已經在運行了，再來看看/tmp目錄下的內容
可以看到，已經有daemon.log日志文件了。
然後使用命令：tail -f /tmp/daemonl.log ,可 以看到該程序每隔10s就會在對應的文件中輸入相關的內容
到這裡，這個實驗就已經結束 了，通過前邊使用命令：ps -ef|grep ./daemon可以看到咱們這個進程的進程號是3346，現在使用命令:kill -9 3346將這個進程殺死，同時也把/tmp中的daemon.log文件頁刪除，方便咱們下邊的實驗。
守護進程的出錯處理
在編寫守護進程的具體調試過程中會發現，由於守護進程完全脫離了控制終端 ，因此，不能像其他普通進程一樣，將錯誤信息輸出到控制終端來通知程序員，即使使用gdb也無法正常調試 。那麼，守護進程的進程要如何調試呢？一種通用的方法是使用 syslog 服務，將程序中的出錯信息輸入到系 統日志文件中（如“/var/log/messages”）,從而可以直觀地看到程序的問題所在（“/var/log/message”系 統日志文件只能由擁有root權限的超級用戶查看。在不同的Linux發行版本中，系統日志文件路徑全名可能有 所不同，例如，我的ubuntu中路徑就是“/var/log/syslog”）。
syslog 是Linux中的系統日志管理服 務，通過守護進程 syslogd 來維護。該守護進程在啟動時會讀一個配置文件“/etc/syslog.conf”,該文件決 定了不同種類的消息會發送到何處。例如，緊急消息可被送到系統管理員並在控制台上顯示，而警告消息則可 被記錄到一個文件中。
該機制提供了3個syslog相關函數，分別為 openlog()、syslog()和closelog (),下面就分別介紹這3個函數。
函數說明
openlog()函數用於打開系統日志服務的一個鏈 接;syslog()函數用於向日志文件中寫入信息，在這裡可以設定消息的優先級、消息輸出格式等;closelog()函 數用於關閉系統日志服務的鏈接。
函數格式
基礎實驗
咱們可以嘗試用普通身份執行程序(redhat中不要用root，ubuntu正常運行就可以)。由於這裡的open()函 數必須具有root權限，因此，syslog 會將錯誤信息寫入到系統日志文件("如/var/log/syslog")中 ，結果如下圖
本實驗文件syslog_damen.c下載：http://download.csdn.net/detail/mybelief321/5559631