What are pid and lock files for?
I often see that programs specify pid and lock files. And I’m not quite sure what they do. For example, when compiling nginx:
--pid-path=/var/run/nginx.pid \ --lock-path=/var/lock/nginx.lock \ 3 Answers 3
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).
The idea with lock files is the following: the purpose is for 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.
Operating systems or runtime platforms typically offer synchronization primitives and it’s usually a better decision to use those instead. There may be situations such as writing something that’s meant to run on a wide variety of operating systems past and future without a reliable library to abstract the calls (such as possibly sh or bash based scripts meant to work in a wide variety of unix flavors) — in that case this scheme may be a good compromise.
Для чего нужны файлы pid и lock?
Я часто вижу, что программы указывают файлы pid и lock. И я не совсем уверен, что они делают.
Например, при компиляции nginx:
--pid-path=/var/run/nginx.pid \ --lock-path=/var/lock/nginx.lock \ Может кто-нибудь пролить свет на этот?
pid-файлы пишутся некоторыми программами для записи их идентификатора процесса во время их запуска. Это имеет несколько целей:
- Это сигнал другим процессам и пользователям системы, что эта конкретная программа запущена или, по крайней мере, успешно запущена.
- Это позволяет очень легко написать скрипт, проверить, работает ли он, и выполнить простую kill команду, если кто-то хочет завершить его.
- Для программы это дешевый способ узнать, не был ли предыдущий запущенный экземпляр успешно завершен.
Разумеется, наличие pid-файла не гарантирует, что этот конкретный идентификатор процесса работает, поэтому этот метод не на 100% надежен, но во многих случаях «достаточно хорош». Проверка наличия определенного PID в таблице процессов не является полностью переносимой в UNIX-подобных операционных системах, если только вы не хотите зависеть от ps утилиты, которую может быть нежелательно вызывать во всех случаях (и я считаю, что некоторые UNIX-подобные операционные системы В ps любом случае реализовать по- другому).
Файлы блокировки используются программами для обеспечения того, чтобы два (с хорошим поведением) отдельных экземпляра программы, которые могут одновременно работать в одной системе, не обращались к чему-то другому одновременно. Идея состоит в том, что прежде чем программа получит доступ к своему ресурсу, она проверяет наличие файла блокировки, и, если файл блокировки существует, либо выдает ошибку, либо подождите, пока она не исчезнет. Когда он не существует, программа, желающая «приобрести» ресурс, создает файл, а затем другие экземпляры, которые могут встретиться позже, будут ожидать завершения этого процесса. Конечно, это предполагает, что программа, «получающая» блокировку, фактически снимает ее и не забывает удалить файл блокировки.
Это работает, потому что файловая система во всех UNIX-подобных операционных системах обеспечивает сериализацию , что означает, что в любой момент времени происходит только одно изменение файловой системы. Вроде как блокировки с базами данных и тому подобное.
Это правильно, если только файл блокировки не удален вручную. VMWare Player демонстрирует это поведение, например, если VMWare Player дает сбой, вы должны удалить .lck файл в каталоге виртуальной машины, в противном случае он сообщит вам, что он используется, когда вы попытаетесь запустить его.
Я не думаю, что программы для Windows работают так. Единственные программы с таким поведением, которые я видел, это порты из Unix / Linux
LawrenceC, Re » Когда его не существует, программа, желающая» приобрести «ресурс, создает файл «; Но есть специальные функции, специально созданные для такой синхронизации. Почему бы не полагаться на эти функции вместо того, чтобы использовать «взлом файла»?
@Pacerier — таким образом, файлы блокировки, вероятно, чаще используются такими вещами, как сценарии оболочки или программы, которые могут взаимодействовать со сценариями оболочки, поскольку оболочки Unix / Linux очень легко взаимодействуют с файловой системой, в отличие от других примитивов синхронизации. Файлы также легко сохраняются в разных процессах. Высокопроизводительная программа, очевидно, предпочла бы использовать собственные примитивы ОС по сравнению с файлами для внутренней синхронизации или даже по сравнению с другими процессами, которые не являются оболочками.
Эти файлы часто используются демонами, которые должны запускаться в системе только один раз. Файл PID обычно содержит идентификационный номер процесса уже запущенной и запущенной программы, если таковая существует. Кроме того, когда он запускается, он создает файл блокировки. Пока существует файл блокировки, он не сможет запустить другой без вмешательства пользователя. Если файл блокировки существует, а идентификатор процесса, указанный в файле pid, не запущен, демон считается находящимся в «мертвом» состоянии, то есть он должен работать, но, вероятно, не из-за сбоя или неправильного завершения работы , Это может инициировать специальный сценарий запуска / перезапуска для некоторых программ. Правильное выключение приведет к удалению файла блокировки.
What is a .pid file and what does it contain?
I recently came across a file with the extension .pid and looked inside it but didn’t find much. The documentation says:
A Pid-File is a file containing the process identification number (pid) that is stored in a well-defined location of the filesystem thus allowing other programs to find out the pid of a running script.
4 Answers 4
The pid files contains the process id (a number) of a given program. For example, Apache HTTPD may write its main process number to a pid file — which is a regular text file, nothing more than that — and later use the information there contained to stop itself. You can also use that information to kill the process yourself, using cat filename.pid | xargs kill
Why not look up the process by name then? Why bother with maintaining .pid files when you can just run «pidof $process_name» and get the ID?
@Shnatsel: because there might be two processes with that name running, and you need to know which one is in charge of that PID file. There are other reasons, more details are found here: unix.stackexchange.com/questions/12815/…
In that case there would be 2 pid files and you’s be facing the same issue as with PID lookups. So pidfiles do not to any good and only complicate things in this scenario as well as any other scenario I can think of. I suspect they either appeared before procfs did or they’re used as portability tool because procfs interfaces are different on e.g. Solaris are quite different from that on Linux.
Just one thing: echo filename.pid | xargs kill will not kill the process. I guess you meant: echo $(cat filename.pid) | xargs kill or echo
@AlexandrodeOliveira Is there an advantage of using echo and cat instead of just cat filename.pid | xargs kill ?
Not sure if that’s these are the only reasons, but here’s my the drill:
Depending on the way you write a shellscript to kill the desired proccess you could end up killing the kill PID before it kills your target, let’s take mydaemon for example:
kill -9 `ps ax | grep mydaemon | awk '< print $1 >'` A) SIGPIPE-ing kill In a 32-bit Linux PID is usually a 15-bit integer, overflows do happen often, there’s a fairly big chance that the grep or awk PIDs will appear prior to mydaemon’s one. In 64-bit PID numbers are usually 22-bit, it’s more than 100x less likely to happen, yet still pretty factible.
By killing either one of your pipes you’ll receive a SIGPIPE and usually this means death as well, therefore kill would be killed before killing mydaemon rendering the kill attempt a fail.
B) Killing other PIDs Also, say you had vi /etc/mydaemon/mydaemon.conf running altogether, that PID might also be killed, not to mention other users’ processes since you much likely would be issuing such command as root.
C) It’s a simple unix-like lock -> No additional code/daemon required. PidFiles make a fairly simple way to create user-manageable locks to keep you from spawning a daemon twice inadvertently.