Найти PID процесса, который заблокировал файл

Question

Мне нужно найти, кто заблокировал файл с помощью python (posix / linux).В настоящее время я использую этот метод:

flk = struct.pack('hhqql', fcntl.F_WRLCK, 0, 0, 0, 0)
flk = struct.unpack('hhqql', fcntl.fcntl(self.__file, fcntl.F_GETLK , flk))

if flk[0] == fcntl.F_UNLCK:
    # file is unlocked ...
else:
    pid = flk[4]

Это решение не зависит от архитектуры.Структура, переданная в fcntl, содержит такие поля, как off_t или pid_t.Я не могу делать предположения о размерах этих типов.

struct flock {
    ...
    short l_type;    /* Type of lock: F_RDLCK,
                    F_WRLCK, F_UNLCK */
    short l_whence;  /* How to interpret l_start:
                    SEEK_SET, SEEK_CUR, SEEK_END */
    off_t l_start;   /* Starting offset for lock */
    off_t l_len;     /* Number of bytes to lock */
    pid_t l_pid;     /* PID of process blocking our lock
                    (F_GETLK only) */
    ...
};

Есть ли другой способ найти PID?Или, может быть, размеры off_t и pid_t?Решение должно быть полностью переносимым между различными архитектурами.

Редактировать Я решил использовать программу lsof , как предложено ниже.Другой вариант - проанализировать файл / proc / locks.

Answer 1

Может быть, вы можете попробовать использовать для этого внешнюю программу lsof?

   Lsof revision 4.85 lists on its standard output file information 
   about files opened by processes for the following UNIX dialects:

        AIX 5.3
        Apple Darwin 9 and Mac OS X 10.[56]
        FreeBSD 4.9 and 6.4 for x86-based systems
        FreeBSD 8.[02] and 9.0 for AMD64-based systems
        Linux 2.1.72 and above for x86-based systems
        Solaris 9, 10 and 11

Answer 2

Ранее я использовал 'hhllh', потому что думал, что он будет наиболее точно отображаться на off_t на разных платформах. Но в итоге я остановился на 'hhqqh', который работает для меня на 32-битных и 64-битных системах.

Я был удивлен этим решением, но то, что происходит с 32-битными блоками, на которые я смотрел, это bits/fcntl.h создает структуру flock с off64_t, если система уже не определяет __USE_FILE_OFFSET64 (в в этом случае он просто использует обычный 'ol off_t), поэтому кажется, что размер l_start и l_len всегда равен 8 (структурный формат python char 'q' равен long long).

Это, вероятно, не совсем переносимо, я не могу сказать, что все современные 32-битные системы будут делать это, но пока это было достаточно хорошо для меня - поэтому я решил упомянуть об этом на случай, если другие (например, я) предпочел бы не запускать другой процесс и делать кучу разборов строк, YMMV. Также, если я неправильно понимаю (или плохо объясняю), почему эта строка формата работает на обеих платформах - может быть, кто-то может исправить меня?