Как в процессе найти переменную

Время на прочтение
4 мин

Количество просмотров 26K

Часто бывает так, что приходишь на машину и обнаруживаешь какой-то скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Где искать этот run.php? Или добавляешь запись в /etc/crontab, а скрипт там падает с ошибкой «command not found». Почему? И что делать? 

У меня есть ответы на эти вопросы.

Переменные окружения

Практически во всех современных операционных системах у процессов существуют переменные окружения. Технически они представляют собой набор именованных строк. Если запускается подпроцесс, то он автоматически наследует копию окружения родителя. 

Среди прочих есть переменная PATH, которая указывает пути для поиска исполняемых файлов, переменная HOME, которая указывает на домашнюю директорию пользователя, переменные, отвечающие за языковые предпочтения пользователя, и многие другие. 

Есть множество обзоров, описывающих значения этих переменных, а вот статей о том, как расследовать проблемы, практически нет. Восполним этот пробел.

Кто запустил процесс?

Итак, мы обнаружили скрипт, запущенный под системным пользователем неделю назад. Кто его запустил? Зачем? Может, про него просто забыли? Запустить его потенциально могли человек 10–15, всех не опросишь. Как найти, кто же это был? И где лежит этот run.php?

$ ps x  | grep run.php
10684 ?    	Ss   472:25 /local/php/bin/php run.php 

На помощь приходят переменные окружения процесса и особенность sudo. Есть такая переменная PWD, в которой оболочка хранит текущую рабочую директорию; это значение, по сути, сохраняет информацию о текущей директории в момент запуска команды. Также утилита sudo по умолчанию оставляет в переменной окружения процесса информацию о том, из-под какого пользователя была запущена она сама. 

Переменные окружения (и многое другое) для любого запущенного процесса можно посмотреть в /proc. Вуаля:

$ cat /proc/10684/environ | tr '' 'n' | grep SUDO_USER
SUDO_USER=alexxz
$ cat /proc/10684/environ | tr '' 'n' | grep PWD
PWD=/home/etlmaster

Кхм, сам и запустил. Ну с кем не бывает?.. 

В общем, вот таким нехитрым методом в простых ситуациях можно найти информацию о процессе, которая в общем случае недоступна.

Скрипт работает из командной строки, но не работает из cron

Одним из случаев, когда приходится вспоминать о переменных окружения, является ситуация, когда добавленный в /etc/crontab скрипт падает с ошибкой. Заходишь на сервер по SSH, запускаешь команду, всё вроде работает как надо. А при автоматическом запуске показывает что-то типа «hive: command not found». 

Вообще есть хорошая практика прописывать полный путь до исполняемых команд, однако это не всегда возможно. В таких случаях разработчики выкручиваются кто как может. Кто-то добавляет нужный путь в PATH частью команды в кронтабе. Более опытные оборачивают свою команду в bash -l. А наученные горьким опытом крон-бомбы ещё и flock довернуть не забывают. Всё так: сделал, добавил в мониторинг и забыл.

После таких манипуляций в душе настоящего инженера остаётся некий осадочек. Да, задача решена. Но я же ни фига не понял, что происходит! Чем один подход лучше другого? Где все эти настройки хранятся и кем меняются?

Давайте сравним переменные окружения, которые есть у процесса, когда он запускается из крона, и переменные окружения, которые есть у нас в командной строке. Логируем вывод команды env из крона и своё текущее окружение:

$ echo "* * * * * env > ~/crontab.env" | crontab; sleep 60; echo "" | crontab;
$ env > my.env

Смотрим, что там в переменной PATH:

> grep ^PATH= crontab.env my.env
Crontab.env:
PATH=/usr/bin:/bin
My.env:
PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/local/hadoop/bin:/usr/local/bin:/usr/bin:/bin

Мама мия! Так там под кроном только самый минимум! Конечно же, надо подгружать нормальные переменные окружения. 

Давайте посмотрим, какое окружение будет, если добавить bash -l:

$ echo "* * * * * bash -l env > ~/crontab.env" | crontab; sleep 60; echo "" | crontab;

alexxz@bi1.mlan:~> grep ^PATH= crontab.env my.env
Crontab.env:
PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/usr/local/bin:/usr/bin:/bin
My.env:
PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/local/hadoop/bin:/usr/local/bin:/usr/bin:/bin

Разница уже не так заметна. Все пути представлены. Некоторые в другом порядке, некоторые повторяются, но это уже намного лучше, чем было. Остальные переменные тоже неплохо настроены. Есть, конечно, небольшая разница в локали, в переменных от SSH, но это уже не должно драматично влиять на работу скрипта. 

Теперь понятно, почему bash -l просто необходим в crontab-записях. И, конечно же, не забываем про flock.

Отлаживаем инициализацию логин-скриптов

Проблема вроде бы решена, всё из крона работает. Но как же получается, что некоторые пути дублируются в переменной PATH? Значит, есть какой-то беспорядок в настройке сервера. Давайте попробуем разобраться. 

Открываем какой-нибудь ман по инициализации окружения, вычитываем, какие скрипты и в каком порядке выполняются, с воодушевлением начинаем пробегать их глазами — и через несколько минут приходит чувство отчаяния. Какой-то бесконечный поток условий про какие-то особые случаи архитектур, терминалов и невероятно важных настроек цветов для команды ls. Боль, отчаяние, ненависть! Нас интересует одна чёртова переменная PATH!

На самом деле всё несколько проще. Знакомьтесь:

env -i bash -x -l -c 'echo 123' > login.log 2>&1

Что делает эта команда? Создаёт новый процесс bash с девственно чистым окружением, указывает, что надо запустить скрипты инициализации и всё подробно залогировать в файле login.log. Теперь у нас есть возможность не выполнять в уме все скрипты, а просто прочитать, что, где и когда выполнилось и откуда появилась та или иная настройка окружения.

Я не буду детально разбирать, как читать получившийся лог. Там всё почти тривиально. Упомяну лишь, что одно попадание у меня оказалось из /etc/profile и два — из /etc/bash.bashrc. Да, где-то перемудрили при настройке пакетов в паппете. Ну ничего, мне работать это не мешает.

Зато теперь я знаю и умею!

P. S. В совсем сложных случаях и чтобы разобраться вообще во всём, можно обернуть команду в strace:

 strace -f env -i bash -x -l -c 'echo 123' > login.log 2>&1

В этой статье будет описано взаимодействие с окружением, а также чтение и установка переменных окружения и оболочки напрямую и через конфигурационные файлы. Все дальнейшие действия должны быть релевантны на любой системе Linux.

• Введение
• Как работает окружение и его переменные
• Вывод переменных оболочки и окружения
  • Общие переменные окружения и консольной оболочки
• Установка переменных окружения и оболочки
  • Создание переменной оболочки
  • Создание переменной окружения
• Отвязка переменный
• Установка переменных окружения по логину
  • Различие между логин, не-логин, интерактивной и не-интерактивной сессией оболочки
  • Реализация переменных окружения
• Заключение

Введение

Когда происходит взаимодействие через сессию оболочки, имеется множество информации, которую консольная оболочка обрабатывает для определения своего поведения и доступа к сторонним ресурсам. Некоторые из этих настроек находятся в конфигурационных настройках, а другие определены самим пользователем.

Место, в котором оболочка держит пути всех этих настроек, называется окружением. Окружение — это место, которое оболочка определяет каждый раз, когда запускается сессия. В ней заключены переменные, созданные свойствами системы.

Как работает окружение и его переменные

Окружение обеспечивает набор переменных, через которые оболочка может получать или определять настройки, и пропускать их через дочерние процессы. Различные системные и пользовательские файлы могут обращаться к окружению.

Окружение реализовано как строка, состоящая из пары ключ-значение. Если определяется несколько значений, то они последовательно разделены знаком двоеточия. Каждая пара будет выглядеть как:

KEY=value1:value2:...

Если значение содержит пробелы, тогда используют кавычки

KEY="value with spaces"

Ключами в данных примерах являются переменные. Они могут быть одним из двух типов: переменной окружения и переменной оболочки.

Переменные окружения это переменные, определенные для текущей оболочки — они наследуются любым потомком оболочки и запущенного процесса. Эти переменные используются, чтобы пропускать информацию в процессы, которые образуются от самой оболочки.

Переменные оболочки это переменные, которые содержатся исключительно в оболочке, где они были определены или установлены. Они часто используются для хранения путей, например, как текущая рабочая директория.

По правилам — эти типы переменных определяются, используя заглавные символы. Эта особенность помогает пользователям определять контекст употребления переменных.

Вывод переменных оболочки и окружения

Каждая сессия оболочки хранит пути своих собственных переменных и переменных окружения. Их достигнуть можно разными способами.

Можно распечатать список всех переменных окружения используя env или printenv. По умолчанию они должны делать все то же самое:

printenv

XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/rgt
USER=rgt
DESKTOP_SESSION=cinnamon
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/782e62a7_614a_44c6_a444_cecbdf372225
DEFAULTS_PATH=/usr/share/gconf/cinnamon.default.path
QT_QPA_PLATFORMTHEME=qt5ct
PWD=/home/rgt
HOME=/home/rgt
SSH_AGENT_PID=1365
QT_ACCESSIBILITY=1
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/share/cinnamon:/usr/share/gnome:/home/rgt/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
NVM_IOJS_ORG_MIRROR=https://iojs.org/dist
XDG_SESSION_DESKTOP=cinnamon
LC_ADDRESS=ru_RU.UTF-8
LC_NUMERIC=ru_RU.UTF-8
GTK_MODULES=gail:atk-bridge
PAPERSIZE=a4
TERM=xterm-256color
SHELL=/bin/bash
VTE_VERSION=5202
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_CURRENT_DESKTOP=X-Cinnamon
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
GNOME_TERMINAL_SERVICE=:1.124
NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist
XDG_SEAT=seat0
SHLVL=1
LANGUAGE=en_US
LC_TELEPHONE=ru_RU.UTF-8
GDMSESSION=cinnamon
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LOGNAME=rgt
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/home/rgt/.Xauthority
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_CONFIG_DIRS=/etc/xdg/xdg-cinnamon:/etc/xdg
PATH=/home/rgt/.gems/bin:/home/rgt/.npm-global-modules/bin:/home/rgt/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/elixir/bin:/home/rgt/.racket/bin
LC_IDENTIFICATION=ru_RU.UTF-8
PS1=$ 
SESSION_MANAGER=local/rgt-laptop:@/tmp/.ICE-unix/1301,unix/rgt-laptop:/tmp/.ICE-unix/1301
LESSOPEN=| /usr/bin/lesspipe %s
LC_TIME=en_US.UTF-8
_=/usr/bin/printenv

Как правило, этот вывод довольно типичен для обоих команд. Различия между ними в функциональности. Например, в printenv можно запрашивать значения определенной переменной.

$ printenv SHELL
/bin/bash
$ printenv USER
rgt

С другой стороны env позволяет изменять окружение, указывая определение переменной. Например:

env VAR1="value VAR1" command_to_run command_option

Дочерние процессы, как правило, наследуют переменные окружения от родительского процесса, и это дает возможность переписывать значения или добавлять дополнительные переменные для потомков.

Если посмотреть на вывод команды printenv, то там есть несколько переменных окружения, которые установлены через нашу файловую систему и процессов без нашего ввода.

Это были переменные окружения, но выглядят как переменные консольной оболочки.

Существует команда set, которую можно использовать для отображения. Если ввести set без дополнительных параметров, будет выводиться список всех переменных консольной оболочки, переменные окружения, локальные переменные и функции оболочки:

$ set | head
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_COMPLETION_VERSINFO=([0]="2" [1]="8")
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="4" [1]="4" [2]="19" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu")

Вывод этой команды довольно огромен. Для удобства работы с этими переменными можно использовать пейджеры more или less.

В принципе, отсутствует особая необходимость знать все функции, определенные для bash. Поэтому — можно очистить вывод, указав, что set должен проводить операции в режиме POSIX, которые опускают отображение функций консольной оболочки. Это можно выполнить в дочерней оболочке, чтобы наше текущее окружение оставалось прежним:

(set -o posix; set)

Возникнет список всех определенных переменных окружения и оболочки.

Можно попробовать сравнить этот вывод с выводом команд env или printenv, тем самым получив список только переменных оболочки. Возможно, вывод будет довольно кривым:

comm -23 <(set -o posix; set | sort) <(env | sort)

Отображение будет до сих пор включать несколько переменных окружения, в связи с тем фактом, что set команда выводит значения в кавычках, в то время как команды printenv и env показывают значения, опуская их.

Все это должно давать правильное понимание переменных окружения и оболочки.

Эти переменные используются для всех необходимых вещей. Они обеспечивают альтернативный способ определения постоянных значений для сессии — между процессами, тем самым избегая изменений в файле.

Общие переменные окружения и консольной оболочки

Некоторые переменные окружения и оболочки очень полезны и к ним часто обращаются.
Здесь перечислены общие переменные окружения, которые зачастую используются:

• SHELL: отображает путь к оболочке, которая занимается интерпретацией тех или иных команд, которые вводит пользователь. Как правило, по умолчанию, это будет интерпретатор bash, но возможно и применение других значений, которые можно указать.

• TERM: указывает тип терминала, который эмулируется, когда запускается консольная оболочка. Могут эмулироваться различные терминалы для необходимых операционных требований.

• USER: имя текущего пользователя оболочки.

• PWD: переменная отображает значение текущей рабочей директории.

• OLDPWD: предыдущая рабочая директория. Оболочка держит эту переменную для обратного переключения, когда запускается команда cd -.

• LS_COLORS: определяет цвет кодов, которые используются для вывода команды ls. Чтобы различать типы файлов и директорий.

• MAIL: отображает электронную почту текущего пользователя.

• PATH: список директорий, которые будет проверять система, когда будет идти обращение к той или иной команде. Когда пользователь вводит команду, система смотрит указанные директории, в последовательном порядке.

• LANG: текущий язык и локализационные настройки, включая кодировку символов.

• HOME: текущая домашняя директория пользователя.

• _: отображает вывод последней запущенной команды.

В дополнение к этим переменным окружения, имеются некоторые переменные оболочки, которые также будут часто встречаться:

• BASHOPTS: список опций, которые используются при запуске bash. Это может быть полезно для выяснения, каким конкретно способом будет оперировать консольная оболочка.

• BASH_VERSION: отображает конкретную версию bash.

• BASH_VERSINFO: мажорная версия bash.

• COLUMNS: число колон, используемых для отображения вывода в оболочке.

• DIRSTACK: директории, которые доступны для команд pushd и popd.

• HISTFILESIZE: количество линий, хранящиеся в файле истории набранных команд.

• HISTSIZE: количество линий, которые можно хранить в памяти.

• HOSTNAME: имя компьютера системы на данный момент.

• IFS: внутренний разделитель поля в командной строке. По умолчанию — это пробел.

• PS1: строка приглашения на ввод. Эта переменная используется для того, чтобы определить, как будет выглядеть эта строка. Еще есть вторая строка PS2 которая используется, когда команда многострочная.

• SHELLOPTS: опции оболочки, которые можно определять с помощью команды set.

• UID: идентификатор текущего пользователя.

Установка переменных окружения и оболочки

Для лучшего понимания различий между двумя видами переменных и представления синтаксиса их определения, мы покажем примеры этого процесса.

Создание переменной оболочки

Определение этой переменной будет происходить в пределах текущей сессии консольной оболочки.

$ TEST_VAR='Hello World!'

Кавычки здесь используются, поскольку значение переменной содержит пробел. В дальнейшем будут использоваться одинарные кавычки — это позволит сделать так, что особые знаки в bash будут правильно отображаться.

Определенная выше переменная теперь доступна в текущей сессии, но в дочернем процессе она будет отсутствовать. Увидеть ее можно при помощи команды grep на вывод set:

$ set | grep TEST_VAR
TEST_VAR='Hello World!'
$ bash                # создание новой дочерней сессии
$ set | grep TEST_VAR # делаем поиск переменной
$                     # вывод пуст

Если запустить команду exit, тогда оболочка выходит на родительскую сессию, в которой уже определена данная работающая переменная. Также можно убедиться в отсутствии данной переменной в окружении, сделав ту же проверку:

$ printenv | grep TEST_VAR
$ # вывод пуст

Чтобы получить значение той или иной переменной, используется следующая конструкция:

$ echo $TEST_VAR
Hello World!

Команда echo делает вывод введенной строки как аргумента. Но, в данном случае применяется знак $, в совокупности с ключом переменной, который возвращает ее значение.

Создание переменной окружения

Чтобы обернуть созданную переменную оболочки в переменную окружения, можно ее экспортировать:

$ export TEST_VAR
$ printenv | grep TEST_VAR
TEST_VAR=Hello World!

Если создать новую дочернюю сессию, то можно увидеть, что в ней также существует эта переменная:

$ bash
$ echo $TEST_VAR
Hello World!

Дочерний процесс принял переменную, созданную предыдущей сессией. Также можно попробовать определить переменную в текущем процессе и проверить ее наличие в родительском:

$ export NEW_VAR="Testing export"
$ printenv | grep NEW_VAR
NEW_VAR="Testing export"
$ exit # делаем выход из текущего процесса и возвращаемся в родительский
$ echo $NEW_VAR
$ # ничего

Переменные окружения проходят только в дочерние процессы. Переменная NEW_VAR была определена в дочернем окружении переменных. Она была бы также доступна любым другим дочерним сессиям от этой текущей. Вернувшись обратно — в основную сессию, — через команду exit, предыдущее окружение вместе с этой переменной было стерто.

Отвязка переменный

На данный момент переменная TEST_VAR находится в окружении. По необходимости можно делать отвязку переменных.

$ export -n TEST_VAR

Теперь, если посмотреть в окружение, то удаленная переменная там будет отсутствовать.

$ printenv | grep TEST_VAR

При этом она до сих пор существует в переменной оболочки:

$ set | grep TEST_VAR
TEST_VAR='Hello World!'

Если возникает потребность окончательно сделать отвязку переменной из оболочки и окружения, то можно применить команду unset:

$ unset TEST_VAR

Проверить результат команды можно с помощью echo:

$ echo $TEST_VAR

Отсутствует какое-либо возвращаемое значение, потому что переменная была отвязана.

Установка переменных окружения по логину

Как упоминалось выше, множество программ используют переменные окружения, чтобы решать, как конкретно производить операции. И вместо того, чтобы каждый раз делать вручную определение всех переменных, лучше определять переменные автоматически.

На самом деле, это более сложная проблема, чем кажется сперва, поскольку различные конфигурационные файлы, которые bash читает при запуске — и это зависит от того, как все запущено.

Различие между логин, не-логин, интерактивной и не-интерактивной сессией оболочки

Bash оболочка читает различные конфигурационные файлы в зависимости от того, какая сессия запущена.

Логин-сессия оболочки запускается по аутентификации пользователя. Если пользователь входит в сессию терминала или через SSH и аутентифицируется, тогда эта сессия оболочки будет определена как логин-оболочка.

Если начинается новая сессия bash-оболочки в пределах аутентифицированной сессии, подобно вызову команды bash из консоли, тогда такая оболочка определяется без логина и сразу запускается.

Помимо этих типов сессий, существуют интерактивный и не-интерактивный подход. Первый прикрепляется к терминалу, второй же — наоборот.

Таким образом сессии оболочки могут различаться по этим двум типам.

Обычная сессия, начинающаяся с SSH, обычно является интерактивной оболочкой с логином. Скрипты, запускающиеся из командной строки, обычно являют собой не-интерактивной и не-логин оболочкой. Терминальная сессия может быть составлена из любых комбинаций этих двух свойств.

В независимости от того, какая сессия определена как логин или не-логин, существуют некоторые заявления, по которым происходит инициализация сессии оболочки.

Логин сессия при запуске в первую очередь будет читать конфигурационные заявления из файла /etc/profile. Затем она будет смотреть данные в первом конфигурационном файле и пользовательской домашней директории, чтобы получить особые настройки пользователя.

Читаются исключительно файлы, которые располагаются в ~/.bash_profile, ~/.bash_login и ~/.profile.

В не-логин сессии оболочка читает файл /etc/bash.bashrc и пользовательский ~/.bashrc файл для построения своего окружения.

Не-интерактивные оболочки читают переменную окружения под названием BASH_ENV и читают указанный файл, чтобы определить новое окружение.

Реализация переменных окружения

Как можно увидеть выше, существуют различные отдельные файлы для настроек.

Это обеспечивает гибкость, которая может помочь в особых ситуациях, где будут необходимы конкретные настройки для логин и не-логин оболочки. Хотя, обычно, настройки одинаковы в обоих ситуациях.

Большинство Linux-дистрибутивов производят конфигурацию файлов к источнику не-залогиненых конфигурационных файлов. Это значит, что можно определять окружение переменных внутри них. И они будут прочитаны в обоих случаях.

Обычно в конфигурациях указываются особые переменные окружения для пользовательских нужд. Эти настройки указываются в ~/.bashrc файле.

Внутри этого файла будет уже содержаться определенные данные. Большинство из определений нужны для настройки bash-опций, которые мало связаны с окружением переменных. Переменные внутри файла устанавливаются так же, как и в командной оболочке:

export VARNAME=value

Любое новое окружение переменных может быть добавленно в этот файл. Желательно добавлять новые данные в конец файла — это позволит быстрее их найти в случае, если нужно что-либо изменить. При следующем запуске оболочки, после изменения этого файла, указанные переменные будут прочитаны и пропущены в окружение оболочки. Возможно также и текущую сессию обновить, прочитав файл, введя следующую команду:

$ source ~/.bashrc

Если необходимо установить системные переменные, то можно добавить их в /etc/profile, /etc/bash.bashrc или /etc/environment.

Заключение

Переменные окружения и оболочки всегда представляются в сессиях оболочки и могут быть довольно полезными. Они являются интересным способом установки конфигурационных деталей родительских процессов для их дочерних, а также позволяют удобно производить настройку через внешние файлы.

Существуют различные сценарии, по которым необходимо читать окружение на системе. Эти инструменты и приемы должны дать хорошее основание для создания этих изменений и корректное их использование.

Статья была переведена отсюда.

надо рыться в стэке процесса. Есть хорошие утилиты как memdump, memfetch, memgrep (в портах). Единственное, что все эти тулзы работают на FreeBSD не очень стабильно, memdump грубо говоря делает dd if=/dev/mem of=/<something> что, (видимо из-за отсутствия лока), может привести в вису. У меня например все время подвисает, наверное так ненадо делать

Вот пример как можно узнать PATH через memgrep у процесса top, который я запустил:

узнать PID

Код:

ps axf |grep top
 3846   1  S+     0:00.68 top

Роемся в стеке

Код:

memgrep -p3846 -s -a stack -f s,PATH
Searching 0x7fbfe75c => 0xffffffff…
   found at 0x7fbfec6e
   found at 0x7fbfed3a
   found at 0x7fbfef19
   found at 0x7fbfef44

Теперь можно посмотреть содержимое по найденому адресу, какова длина – я точно не знаю, поэтому взял 256, на угад.

Код:

memgrep -p3846 -d -a 0x7fbfec6e  -l 256
256 bytes starting at 7fbfec6e (+/- 0) as hexint…
7fbfec6e: 48544150 62732f3d 2f3a6e69 3a6e6962 PATH=/sbin:/bin:
7fbfec7e: 7273752f 6962732f 752f3a6e 622f7273 /usr/sbin:/usr/b
7fbfec8e: 2f3a6e69 2f727375 656d6167 752f3a73 in:/usr/games:/u
7fbfec9e: 6c2f7273 6c61636f 6962732f 752f3a6e sr/local/sbin:/u
7fbfecae: 6c2f7273 6c61636f 6e69622f 6f682f3a sr/local/bin:/ho
7fbfecbe: 6f2f656d 2f67656c 3a6e6962 7273752f me/oleg/bin:/usr
7fbfecce: 636f6c2f 6b2f6c61 2f346564 3a6e6962 /local/kde4/bin:
7fbfecde: 7273752f 636f6c2f 6b2f6c61 2f346564 /usr/local/kde4/
7fbfecee: 006e6962 4c49414d 61762f3d 616d2f72 bin.MAIL=/var/ma
7fbfecfe: 6f2f6c69 0067656c 434f4c42 5a49534b il/oleg.BLOCKSIZ
7fbfed0e: 004b3d45 3d445750 6d6f682f 6c6f2f65 E=K.PWD=/home/ol
7fbfed1e: 4b006765 535f4544 49535345 555f4e4f eg.KDE_SESSION_U
7fbfed2e: 003d4449 52554358 5f524f53 48544150 ID=.XCURSOR_PATH
7fbfed3e: 73752f3d 6f6c2f72 2f6c6163 3465646b =/usr/local/kde4
7fbfed4e: 6168732f 692f6572 736e6f63 2f7e3a3a /share/icons::~/
7fbfed5e: 6f63692e 2f3a736e 2f727375 72616873 .icons:/usr/shar

… то что искомо – найдено.

Ничто собсна не мешает задампить всеадресное пространство занимаемое процессом (его найти несложно), а потом ковыряться в его шлаке через strings или hexdump -C.