Нахождение команды для определенного PID в Linux из Python
Попытайтесь поместить dlls в \System32\Inetsrv каталог. Это - рабочий каталог для IIS на Windows Server.
, Если это не работает попытка, помещая dlls в каталог System32 и файлы зависимости в каталоге Inetsrv.
5 ответов
ПОЖАЛУЙСТА, не используйте файловую систему / proc в производственном коде. Вместо этого используйте четко определенные интерфейсы POSIX, такие как вызовы glibc и стандартные команды оболочки! Сделайте мир Linux более стандартизированным, это действительно необходимо!
То, что вам нужно, хорошо достигается с помощью вызова команды оболочки
ps -p <YOUR PID> -o cmd h
Никакого анализа не требуется!
Не говоря уже о том, что чтение вывода команды оболочки из python не требует больше усилий чем чтение из файла в / proc . И это также делает вашу программу более переносимой!
Файловая система proc экспортирует эту (и другую) информацию. Посмотрите на символическую ссылку / proc / PID / cmd.
Посмотрите / proc / $ PID / cmdline , а затем os.readlink () в / proc / $ PID / exe .
] / proc / $ PID / cmdline не обязательно будет правильным, поскольку программа может изменить свой вектор аргументов или может не содержать полный путь. Три примера этого из моего текущего списка процессов:
avahi-daemon: chroot helperqmgr -l -t fifo -u/ usr / sbin / postgrey --pidfile = / var / run / postgrey .pid --daemonize --inet = 127.0.0.1: 60000 --delay = 55
Первый очевиден - это недопустимый путь или имя программы. Второй - это просто исполняемый файл без имени пути. Третий выглядит нормально, но вся командная строка фактически находится в argv [0] с пробелами, разделяющими аргументы. Обычно у вас должны быть аргументы, разделенные NUL.
Все это показывает, что / proc / $ PID / cmdline (или вывод ps (1)) ненадежен.
Однако, как и / proc / $ PID / exe . Обычно это символическая ссылка на исполняемый файл, который является основным текстовым сегментом процесса. Но иногда после него стоит « (удалено) », если исполняемый файл больше не находится в файловой системе.
Кроме того, программа, которая является текстовым сегментом, не всегда то, что вам нужно. Например, / proc / $ PID / exe из этого / usr / sbin / postgrey примера выше будет / usr / bin / perl . Это будет иметь место для всех интерпретируемых скриптов (#!).
Я остановился на синтаксическом анализе / proc / $ PID / cmdline - взяв первый элемент вектора, а затем ищу в нем пробелы. , и беря все до первого пробела. Если это был исполняемый файл - я остановился на этом. В противном случае я сделал ссылку для чтения (2) на / proc / $ PID / exe и удалил все строки « (удалено) » в конце. Эта первая часть завершится ошибкой, если в имени исполняемого файла действительно есть пробелы. С этим мало что можно сделать.
Кстати. Аргумент использования ps (1) вместо / proc / $ PID / cmdline в этом случае неприменим, так как вы собираетесь вернуться к / proc / $ PID / exe . Вы будете зависеть от файловой системы / proc , так что вы можете читать ее с помощью read (2) вместо pipe (2), fork (2), execve (2), readdir (3). .., напишите (2), прочтите (2). Хотя ps и / proc / $ PID / cmdline могут быть одинаковыми с точки зрения строк кода Python, за кулисами с ps происходит гораздо больше.