pidfile 與 logfile的不同

原文答案：http://unix.stackexchange.com/questions/12815/what-are-pid-and-lock-files-for

大意翻譯如下：

pidfile 是用戶程序正在開始運(yùn)行期間，將進(jìn)程ID寫進(jìn)pidfile文件，主要目的有三個(gè)：

    1.為其他程序或操作系統(tǒng)標(biāo)識(shí)本程序正在運(yùn)行，或至少啟動(dòng)成功了。

    2.如果計(jì)劃要用kill命令終止進(jìn)行，它允許一個(gè)可寫腳本非常容易地檢測(cè)程序運(yùn)行狀態(tài)。

    3.有pidfile后，可以用非常少的代價(jià)去獲取前一個(gè)運(yùn)行實(shí)例因何沒有退出成功

僅僅存在pidfile并不能保證進(jìn)程id是否正在運(yùn)行，這個(gè)方法不是100%簡(jiǎn)單，但對(duì)大多數(shù)程序來說是足夠好的，檢測(cè)進(jìn)程id是否在進(jìn)程表這個(gè)方式并不能跨平臺(tái)使用，除非使用 ps工具。

lockfile 通常用來保證同一程序的兩個(gè)實(shí)例不能同時(shí)運(yùn)行，使用完后別忘記刪除這個(gè)文件

pid files are written by some programs to record their process ID while they are starting. This has multiple purposes:

• It's a signal to other processes and users of the system that that particular program is running, or at least started successfully.

• It allows one to write a script really easy to check if it's running and issue a plain kill command if one wants to end it.

• It's a cheap way for a program to see if a previous running instance of it did not exit successfully.

Mere presence of a pid file doesn't guarantee that that particular process id is running, of course, so this method isn't 100% foolproof but "good enough" in a lot of instances. Checking if a particular PID exists in the process table isn't totally portable across UNIX-like operating systems unless you want to depend on the ps utility, which may not be desirable to call in all instances (and I believe some UNIX-like operating systems implement ps differently anyway).

Lock files are used by programs to ensure two (well-behaved) separate instances of a program, which may be running concurrently on one system, don't access something else at the same time. The idea is before the program accesses its resource, it checks for presence of a lock file, and if the lock file exists, either error out or wait for it to go away. When it doesn't exist, the program wanting to "acquire" the resource creates the file, and then other instances that might come across later will wait for this process to be done with it. Of course, this assumes the program "acquiring" the lock does in fact release it and doesn't forget to delete the lock file.

This works because the filesystem under all UNIX-like operating systems enforces serialization, which means only one change to the filesystem actually happens at any given time. Sort of like locks with databases and such.