Есть ли способ изменить переменные среды другого процесса в Unix?
в Unix есть ли способ, которым один процесс может изменить переменные среды другого (предполагая, что все они выполняются одним и тем же пользователем)? Общее решение было бы лучше, но если нет, то как насчет конкретного случая, когда один является ребенком другого?
Edit: как насчет через gdb?
10 ответов:
через gdb:
(gdb) attach process_id (gdb) call putenv ("env_var_name=env_var_value") (gdb) detachЭто довольно неприятный hack и должно быть сделано только в контексте сценария отладки, конечно.
вы, вероятно, можете сделать это технически (см. другие ответы), но это может вам не помочь.
большинство программ будут ожидать, что env vars не может быть изменен извне после запуска, поэтому большинство из них, вероятно, просто прочитают интересующие их vars при запуске и инициализируют на основе этого. Поэтому изменение их впоследствии не будет иметь значения, так как программа никогда не будет перечитывать их.
Если вы разместили это как конкретную проблему, вы, вероятно, должны принять различный подход. Если бы это было просто из любопытства: хороший вопрос : -).
по существу, нет. Если у вас были достаточные привилегии (root или около того) и вы тыкали вокруг /dev / kmem (память ядра), и вы внесли изменения в среду процесса, и если процесс действительно повторно ссылался на переменную среды после этого (то есть процесс еще не взял копию env var и не использовал только эту копию), то, возможно, если вам повезло и умно, и ветер дул в правильном направлении, и фаза Луны была правильной, возможно,, вы можете чего-то добиться.
Цитируя Джерри Пика:
вы не можете научить старую собаку новым трюкам.
единственное, что вы можете сделать, это изменить переменную окружения ребенка процесс до запуск: он получает копию родительской среды, извините.
посмотреть http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm Для сведения.
просто комментарий к ответу об использовании /proc. Под linux / proc поддерживается, но, это не работает, ты не может изменить
/proc/${pid}/environфайл, даже если вы корень: это абсолютно только для чтения.
Я мог бы придумать довольно надуманный способ сделать это, и он не будет работать для произвольных процессов.
предположим, что вы пишете свою собственную общую библиотеку, которая реализует 'char *getenv'. Затем вы устанавливаете' LD_PRELOAD 'или' LD_LIBRARY_PATH ' env. vars, чтобы оба ваших процесса запускались с предварительно загруженной общей библиотекой.
таким образом, вы по существу будете иметь контроль над кодом функции "getenv". Тогда, вы могли бы сделать все виды неприятных трюков. Ваш 'совместимость' может посоветовать внешний конфигурационный файл или сегмент ШМ для альтернативных значений переменные окружения. Или вы можете выполнить поиск/замену регулярных выражений по запрошенным значениям. Или. ..
Я не могу придумать простой способ сделать это для произвольных запущенных процессов (даже если вы корень), за исключением перезаписи динамического компоновщика (ld-linux.so).
насколько мне известно, нет. На самом деле вы пытаетесь общаться от одного процесса к другому, который вызывает один из методов IPC (общая память, семафоры, сокеты и т. д.). Получив данные одним из этих методов, вы можете установить переменные среды или выполнить другие действия более непосредственно.
или сделать ваш процесс, чтобы обновить файл конфигурации для нового процесса, а затем либо:
- выполните kill-HUP на новом процессе, чтобы перечитывать обновленный файл конфигурации, или
- пусть процесс время от времени проверяет файл конфигурации на наличие обновлений. Если изменения найдены, то перечитайте файл config.
НТН.
спасибо,
Роб
Если ваш unix поддерживает файловую систему /proc, то тривиально читать env - вы можете прочитать среду, командную строку и многие другие атрибуты любого процесса, которым вы владеете таким образом. Меняю его... Ну, я могу придумать способ, но это плохая идея.
более общий случай... Я не знаю, но я сомневаюсь, что есть портативный ответ.
(отредактировано: мой первоначальный ответ предполагал, что OP хотел прочитать env, а не изменить его)
Unix-это полный межпроцессного взаимодействия. Проверьте, есть ли у вашего целевого экземпляра. Dbus становится стандартом в" настольном " IPC.
Я меняю переменные среды внутри удивительного оконного менеджера с помощью awesome-client С является Dbus "отправитель" кода lua.
не прямой ответ, но... у Раймонда Чена было [Windows-based] обоснование вокруг этого только на днях : -
... Хотя есть, конечно, неподдерживаемые способы сделать это или способы, которые работают с помощью отладчика, нет ничего, что поддерживается для программного доступа к командной строке другого процесса, по крайней мере, ничего не предусмотрено ядром. ...
, что не является следствием принципа не отслеживание информации, которая вам не нужна. Ядру не нужно получать командную строку другого процесса. Он принимает командную строку, переданную
CreateProcessфункция и копирует ее в адресное пространство запускаемого процесса, в месте, гдеGetCommandLineфункция может получить его. Как только процесс получит доступ к своей собственной командной строке, обязанности ядра будут выполнены.поскольку командная строка копируется в адресное пространство процесса, процесс может даже записать в память, которая содержит командную строку и изменить ее. Если это произойдет, то исходная командная строка будет потеряна навсегда; единственная известная копия будет перезаписана.
другими словами, любые такие объекты ядра будут
- трудно реализовать
- потенциально угрожает безопасности
однако наиболее вероятной причиной является просто то, что есть ограниченные случаи использования для такого объекта.
Comments