Proc

Список процессов

Вывести на экран список текущих процессов, запущенных пользователем, можно командой:

ps

Чтобы посмотреть список всех процессов с дополнительной информацией, вводим:

ps aux

Мы увидим, примерно, следующее:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       661  0.0  0.0   4072     8 tty1     Ss+  Jul03   0:00 /sbin/mingetty
root       662  0.0  0.0   4072     8 tty2     Ss+  Jul03   0:00 /sbin/mingetty
root     16355  0.0  0.0 171636  3308 pts/0    S    15:46   0:00 sudo su
root     16366  0.0  0.0 140896  1556 pts/0    S    15:46   0:00 su
root     16368  0.0  0.0 108316  1944 pts/0    S    15:46   0:00 bash
root     18830  0.0  0.0 110244  1172 pts/0    R+   16:20   0:00 ps u

* где:

• USER — учетная запись пользователя, от которой запущен процесс.
• PID — идентификатор процесса.
• %CPU — потребление процессорного времени в процентном эквиваленте.
• %MEM — использование памяти в процентах.
• VSZ — Virtual Set Size. Виртуальный размер процесса (в килобайтах).
• RSS — Resident Set Size. Размер резидентного набора (количество 1K-страниц в памяти).
• TTY — терминал, из под которого был запущен процесс.
• STAT — текущее состояние процесса. Могут принимать значения:
  1. R — выполнимый процесс;
  2. S — спящий;
  3. D — в состоянии подкачки на диске;
  4. T — остановлен;
  5. Z — зомби.
  6. W — не имеет резидентных страниц;
  7. < — высоко-приоритетный;
  8. N — низко-приоритетный;
  9. L — имеет страницы, заблокированные в памяти.
• START — дата запуска процесса.
• TIME — время запуска процесса.
• COMMAND — команда, запустившая процесс.

Ключи

Ключ	Описание
-A	Все процессы.
-a	Запущенные в текущем терминале, кроме главных системных.
-d	Все, кроме главных системных процессов сеанса.
-e	Все процессы.
f	Показать дерево процессов с родителями.
T	Все на конкретном терминале.
a	Все, связанные с текущим терминалом и терминалами других пользователей.
r	Список только работающих процессов.
x	Отсоединённые от терминала.
u	Показать пользователей, запустивших процесс.

History

Proc is a common term used primarily in game programming to refer to an event triggered under particular circumstances. For example, in WoW, a particular weapon (that hits many times) might have a 10% chance on each hit to apply a special effect, such as poison damage. When WoW users talk about «how often this weapon procs», they are talking about the likelihood of the special effect occurring.

Proc was originally short for «spec_proc» (spec_proc is short for «special process») which is a term used by the original programmer of Circle-MUD, Jeremy Elson. It might have been used by the original programmers of diku-MUD as well. Special processes in Circle-MUD are functions that can be assigned to objects, players, and locations in the world such that each time an event occurs, the special process function will be invoked. Special processes were used in Circle-MUD for a wide variety of purposes: Creating room events when a person typed a specific string of text, causing a weapon or piece of armor to perform a magical action, and even causing a mob to do something that it wouldn’t normally do.

Special processes were a way of creating unique experiences that could not be achieved by simply building the dungeon and populating it with monsters. Special processes breathed life into these worlds by introducing extra coding that enhanced the gamer’s experience without changing the underlying structure or function of the code-base. If you ever played a MUD and were walking around in a dungeon and randomly saw the text «You feel as though you are being watched,» that was probably a special process.[citation needed]

When developers and players were talking about these special processes they abbreviated the term to «proc». Over time the noun also became a verb, «proced» («proc’d» or «procced»), which meant that the special process was invoked and performed its action. Most often, players were concerned about their weapons and whether or not the weapon would perform its special attack (a proc), and so proc must have started to take on a narrower meaning for MMORPG players who were somewhat more removed from the core combat engine and flat world of MUDs.[citation needed]

Информация об оперативной памяти

1. Файл /proc/meminfo (Linux)

Команда:

cat /proc/meminfo

Пример ответа:

MemTotal:        8010284 kB
MemFree:         1058580 kB
MemAvailable:    2791616 kB
Buffers:            1884 kB
Cached:          1754092 kB
SwapCached:       122280 kB
Active:          4330296 kB
Inactive:        2006792 kB
Active(anon):    3623768 kB
Inactive(anon):   983120 kB
Active(file):     706528 kB
Inactive(file):  1023672 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1048572 kB
SwapFree:         597684 kB
Dirty:                20 kB
Writeback:             0 kB
AnonPages:       4466532 kB
Mapped:            92808 kB
Shmem:             25776 kB
Slab:             408732 kB
SReclaimable:     308820 kB
SUnreclaim:        99912 kB
KernelStack:        7312 kB
PageTables:        23276 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     5053712 kB
Committed_AS:    3770324 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      159328 kB
VmallocChunk:   34359341052 kB
HardwareCorrupted:     0 kB
AnonHugePages:   3248128 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      257984 kB
DirectMap2M:     8130560 kB

* чаще всего, самое важное:

• MemTotal — общий объем оперативной памяти.
• MemFree — объем памяти, который не используется системой.
• Buffers — память, которая в данным момент ожидает записи на диск.
• Cached — объем, задействованный под кэш чтения с диска.
• MemAvailable — объем памяти, доступной в распределители без необходимости обмена.
• SwapTotal — объем файла подкачки.
• SwapFree — свободный объем файла подкачки.

* Объем используемой памяти = MemTotal – MemFree — Cached — Buffers.

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

2. free (Linux)

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

free -m

Пример ответа:

              total        used        free      shared  buff/cache   available
Mem:           3,7G        568M        378M        193M        2,8G        2,6G
Swap:          4,0G         94M        3,9G

sysctl hw.physmem

Пример ответа:

hw.physmem: 2123677696

4. dmesg

Работает на BSD и Linux:

dmesg | grep memory

Итог:

real memory  = 2147483648 (2048 MB)
avail memory = 2042109952 (1947 MB)

5. Другие команды

Для получения информации по оперативной памяти также можно использовать команды:

vmstat -s

top

htop

* для htop необходима установка одноименной утилиты.

Команды для настройки системы

Есть возможность изменять другие параметры (не ядра) во время работы
системы и сделать, чтобы эти изменения оказали эффект без перезагрузки
системы. В основном это сервисы, демоны и серверы, которые прописаны в
директории /etc/init.d. Поскольку в этой директории находится широкий
спектр скриптов, то нет возможности рассмотреть их все здесь. Однако,
ниже будут приведены несколько примеров того, как можно манипулировать
этими скриптами в различных дистрибутивах Linux. Примеры изменения
демона и перезагрузки конфигурации без перезагрузки системы могут быть
полезны при:

• Изменении конфигурации Web сервера и перезагрузки Apache
• Удаления загружаемого в inetd сервиса, которым вы не пользуетесь
• Манипулирования настройками вашей сети
• Экспортирования новой файловой системы через NFS
• Запуска/остановки вашего файервола

Сначала, основной способ манипулирования системными сервисами через
скрипты в /etc/init.d. Эти скрипты используют параметры для управления
своими сервисами. Вы можете ввести в командной строке имя сервиса без
параметров чтобы увидеть допустимые параметры. Общие параметры таковы:

• start: Запускает остановленный сервис
• stop: Останавливает запущенный сервис
• restart: Останавливает и затем запускает сервис; запускает
  остановленный сервис
• reload: Перезагружает конфигурацию сервиса без прерывания его
  соединения
• status: Выводит информацию запущен сервис или нет

В качестве примера следующая команда перезагрузит конфигурацию вашего
xinetd без прерывания любых присоединенных сессий пользователей
(полезно, если вы вносите изменения в ваш /etc/xinetd.conf):

Red Hat предоставляет комнанду service, которая будет управлять
сервисом для вас. Команда service выполняет те же действия, что и ввод
имени скрипта. Синтаксис команды:

Пример:

SuSE также предоставляет команду rc. Она похожа на service, но не
имеет пробела между командой и именем скрипта. Синтаксис команды:

Пример:

Так же как и при изменении параметров ядра, при перезагрузке системы,
все внесенные изменения будут потеряны. Многие дистрибутивы позволяют
использовать команду chkconfig, которая управляет сервисами,
запускаемыми на различных уровнях (включая загрузку). Во время
написания статьи синтаксис команды chkconfig несколько отличался в
различных версиях Linux, но если вы введете команду chkconfig без
параметров, вы получите список возможных параметров и их
использование. Больше информации о chkconfig может быть получено в man
chkconfig(8).

Структура /sys

Базовым понятием модели представления устройств являются объекты (определенные в файле <linux/kobject.h>). Тип по смыслу аналогичен абстрактному базовому классу в объектно-ориентированных языках программирования, таких как С# и Java. Этот тип определяет общую функциональность, такую как счетчик ссылок, имя, указатель на родительский объект, что позволяет создавать объектную иерархию.

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

   struct cdev { 
      struct kobject           kobj; 
      struct module           *owner; 
      struct file_operations  *ops; 
      ...
   };

Во внешнем представлении в каталоге /sys каждому объекту соответствует каталог, что видно и из самого определения структуры:

   struct kobject { 
   ...
      struct kobj_type *ktype;
      struct dentry    *dentry; 
   };

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

int kobject_add( struct kobject *kobj );

Хотя это и не делается в примерах, представленных ниже, так как используемые для регистрации имён в /sys вызовы API () высокого уровня берут эту задачу на себя.

Таким образом, объекты естественным образом отображаются в каталоги пространства имён /sys, которые увязываются в иерархии. Файловая система sysfs — это дерево каталогов без файлов. А как создать файлы в этих каталогах, в содержимом которых отображаются данные ядра? Каждый объект (каталог) содержит (через свой компонент ) массив структур .

   struct kobj_type {
   ...
      struct sysfs_ops  *sysfs_ops;
      struct attribute **default_attrs;
   }

Каждая такая структура struct attribute (определенная в <linux/sysfs.h>) и является определением одного файлового имени, содержащегося в рассматриваемом каталоге:

   struct attribute {
   ...
      char   *name        /* имя атрибута-файла */;
      mode_t  mode struct /* права доступа к файлу */;
   }

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

Этих сведений о sysfs должно быть вполне достаточно для создания интерфейса модуля в пространство имён /sys, но перед тем, как переходить к примеру, остановимся на сходстве и различиях между /proc и в качестве интерфейса для отображения модулем подконтрольных ему данных ядра. Различия систем и складываются, главным образом, на основе негласных соглашений и устоявшихся традиций:

• информация терминальных имён /proc — комплексная, обычно содержит большие объёмы текстовой информации, иногда это таблицы, и даже с заголовками, проясняющими смысл столбцов таблицы;

• информацию терминальных имён /sys (атрибутов) рекомендуется оформлять в виде:

  1. простых;
  2. символьных изображений;
  3. представляющих значения, соответствующие скалярным типам данных языка C ();

Сравним информацию, полученную из систем /proc и /sys:

$ cat /proc/partitions  | head -n5
major minor  #blocks  name
  33     0   10022040 hde
  33     1    3783276 hde1
  33     2          1 hde2
$ cat /sys/devices/audio/dev
14:4
$ cat /sys/bus/serio/devices/serio0/set
2

Как видно, в первом случае — это (потенциально) обширная таблица, с сформированным заголовком, разъясняющим смысл колонок, а во втором — представление целочисленных значений.

Content

Kernel & system information

There are many files under /proc which provide a lot of information about the system as well as the kernel. There are too many to cover them all here, but some of them are listed below with brief information about what they are.

• /proc/cpuinfo — informations about CPU
• /proc/meminfo — information about the physical memory
• /proc/vmstats — information about the virtual memory
• /proc/mounts — information about the mounts(mount)
• /proc/filesystems — information about active filesystems
• /proc/uptime — current system uptime
• /proc/cmdline — kernel command line

Processes

Inside /proc/<pid> is stored information about every process currently running.
Below is an example showing some of the PIDs currently running

$ ls -l /proc

total 0
dr-xr-xr-x  9 root    root                  0 Sep  8 18:17 1
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 10
dr-xr-xr-x  9 daemonx daemonx               0 Sep  9 03:02 1057
dr-xr-xr-x  9 daemonx daemonx               0 Sep  8 18:18 1077
dr-xr-xr-x  9 daemonx daemonx               0 Sep  9 03:02 1087
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 11
dr-xr-xr-x  9 daemonx daemonx               0 Sep  9 03:02 1103
dr-xr-xr-x  9 daemonx daemonx               0 Sep  9 03:02 1107
dr-xr-xr-x  9 daemonx daemonx               0 Sep  9 03:02 1159
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 12
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 124
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 125
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 127
dr-xr-xr-x  9 root    root                  0 Sep  9 03:02 128
...

Lets take for example pid 1057 and see what’s inside

$ ls -l /proc/1057

total 0
dr-xr-xr-x 2 daemonx daemonx 0 Sep  9 03:12 attr
-rw-r--r-- 1 daemonx daemonx 0 Sep  9 03:12 autogroup
-r-------- 1 daemonx daemonx 0 Sep  9 03:12 auxv
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 cgroup
--w------- 1 daemonx daemonx 0 Sep  9 03:12 clear_refs
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 cmdline
-rw-r--r-- 1 daemonx daemonx 0 Sep  9 03:12 comm
-rw-r--r-- 1 daemonx daemonx 0 Sep  9 03:12 coredump_filter
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 cpuset
lrwxrwxrwx 1 daemonx daemonx 0 Sep  9 03:12 cwd -> /home/daemonx
-r-------- 1 daemonx daemonx 0 Sep  9 03:12 environ
lrwxrwxrwx 1 daemonx daemonx 0 Sep  9 03:12 exe -> /usr/lib/gvfsd-metadata
dr-x------ 2 daemonx daemonx 0 Sep  9 03:12 fd
dr-x------ 2 daemonx daemonx 0 Sep  9 03:12 fdinfo
-rw-r--r-- 1 daemonx daemonx 0 Sep  9 03:12 gid_map
-r-------- 1 daemonx daemonx 0 Sep  9 03:12 io
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 latency
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 limits
-rw-r--r-- 1 daemonx daemonx 0 Sep  9 03:12 loginuid
dr-x------ 2 daemonx daemonx 0 Sep  9 03:12 map_files
-r--r--r-- 1 daemonx daemonx 0 Sep  9 03:12 maps
-rw------- 1 daemonx daemonx 0 Sep  9 03:12 mem
...

Some of the fields:

• cmdline — arguments used to start program
• cwd — current working directory for the process
• environ — environment variables inside the process
• fd/ — directory containing open file descriptors for the process
• exe — symbolic link to process executable
• maps — memory mapping of the process
• mem — virtual memory of the process

Изменение параметров работающего ядра

Linux имеет отличный способ изменять параметры ядра во
время работы системы и без необходимости перезагрузки. Это делается при
помощи виртуальной файловой системы /proc. Linux Gazette
дает один из простейших и легчайших объяснений /proc,
которые я когда-либо видел. (см. .)

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

Но может быть слишком много
власти это плохо? Иногда. Если вы собираетесь внести изменения в
файловую систему /proc, вы должны быть уверены, что
вы знаете, что вы делаете и какой эффект произведут на систему ваши
действия. Это очень полезная техника, но одно неверное движение может
вызвать неожиданные последствия

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

Как вносить изменения

Сначала, подумайте о том, как не вносить изменения в
ядро. Есть две отличных причины, почему вам не стоит просто перейти в /proc,
открыть файл в текстовом редакторе, сделать несколько изменений и
сохранить файл. Вот они:

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

Ответом на это является не использование текстового редактора
для внесения изменений. Поэтому для внесения изменения в что-либо в
файловой системе /proc, вам следует использовать команду echo
и перенаправлять вывод команды в выбранный файл в /proc.

Например: echo «Your-New-Kernel-Value» > /proc/your/file

Аналогично, если вы хотите увидеть информацию из /proc,
вам следует использовать либо команду, которая предназначена для этого,
либо команду cat.

Что изменять

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

Каждый файл в /proc имеет особый набор атрибутов
и может принадлежать конкретному пользователю по его ID. Сделано это
очень аккуратно, так что правильная работа обеспечена и администратору
и пользователям. Следующий список обобщает какие атрибуты могут быть у
файлов:

• Read-only: Файл не может быть изменен ни каким
  пользователем; используется для представления системной информации
• Root-write: Если файл может быть изменен, то изменения может
  вносить только пользователь root
• Root-read: Некоторые файлы могут быть не читаемы для
  обычных пользователей системы, только для root
• Other: Вы можете найти другие комбинации, чем перечисленные
  выше, по различным причинам

В основном в /proc вы найдете файлы read-only за
исключением /proc/sys, которая содержит большинство
параметров ядра и предназначена для изменения во время работы системы.
Как результат в этой статье рассматривается в основном эта директория.

Последнее, что вам нужно знать о изменении файлов в /proc
— это то, что нужно записывать в эти файлы. Вы заметите, что некоторые из
файлов могут быть легко прочитаны человеком, а некоторые являются
файлами данных и могут быть прочитаны только при специальных утилит
таких как top, lspci,и free.
Вы также заметите, что эти легко читаемые файлы имеют два различных
формата: некоторые являются бинарными ключами, а другие содержат больше
информации. Файлы с бинарными ключами содержат только 0 (выключено) или
1 (включено) для некоторых функций ядра.

История

8-я редакция UNIX

Впервые procfs появилась в вышедшей в 1985 году 8-й редакции UNIX и была призвана предоставить интерфейс для управления процессами, более удобный, чем вызов ptrace. Она была подробно описана Томом Киллианом в работе «Processes as Files» («Процессы как файлы») в 1984 году. Каждый процесс был представлен файлом, в который могла производиться запись. Количество имеющихся вызовов ioctl равнялось 11.

System V release 4

Данная система, вышедшая в 1990 году, унаследовала procfs из UNIX 8, с некоторыми усовершенствованиями. Процессы по-прежнему представлялись простыми файлами, но были доступны уже 37 вызовов ioctl. ФС стала достаточной для построения на её базе утилит наподобие ps, но оставалась неудобной и плохо расширяемой.

Реализация подробно описана в работе Роджера Фолкнера и Рона Гомеса «The Process File System and Process Model in UNIX System V» в 1991 году.

Plan 9

В 1992 году вышел первый публичный релиз ОС Plan 9. Это был пик развития procfs. Всё управление процессами было перенесено сюда. Процессы стали каталогами вместо файлов. Вместо ioctl стали использоваться текстовые команды, и управление могло производиться командами cat и ls. При монтировании /proc с другого компьютера через сеть локальный процесс мог взаимодействовать с удалённым так, как будто они находились на одной машине.

Solaris 2.6

Solaris 2.6 во многом унаследовал структуру procfs от Plan 9, однако все расположенные там файлы были двоичными, предназначенными для использования программой, а не человеком. В целом файловая система стала несколько примитивнее по сравнению с таковой в Plan 9, но несравнимо более развитой по сравнению с SVR4.

4.4 BSD

Это был ещё один шаг назад по сравнению с Solaris. Количество файлов в каждом каталоге уменьшилось до 8 (хотя в более поздних релизах слегка увеличилось). Набор доступных команд также существенно сократился. Стал происходить обратный переход, от файловых интерфейсов к системным вызовам.

В современных версиях FreeBSD procfs постепенно ликвидируется.

Linux

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

В то же время, свою первоначальную функцию — управление процессами — procfs почти не выполняет. Интерфейс отправки команд отсутствует, файловая система лишь предоставляет подробную информацию о процессах (и кое-где позволяет изменить некоторые опции, например, /proc/<pid>/oom_adj).

find_proc(%args) => \@pids (or \@procs)

Find process by name, PID, or some other attributes. Return an arrayref of PID’s, or an empty arrayref if none match the criteria.

Currently use Proc::ProcessTable to list the processes.

Arguments:

• filter => code

  Filter by a coderef. The coderef will receive the process record (hashref).

• pid => int|array|regex

  Find by PID. Note that if you only want to check whether a PID exists, there are cheaper methods (see ).

• name => str|array|regex

  Match against process’ «name». Name is taken from the first word of the cmndline, with path stripped.

  If value is regex, will do a regex match instead of exact string comparison.

  Example:

• cmndline => str|array|regex

  Match against full cmndline.

  If value is regex, will do a regex match instead of exact string comparison.

• exec => str|array|regex

  Match against program (executable/binary)’s path. If value does not contain a path separator character, will be matched against program’s name.

  Example:

• user => int|str|array|regex

  List processes owned by specified user/UID.

  If given a username which does not exist, will simply not match.

• uid => int|str|array|regex

  Same as .

• euser => int|str|array|regex

  List processes running as certain effective user/UID (will look against ).

  If given a username which does not exist, will simply not match.

• euid => int|str|array|regex

  Same as .

• inverse => bool

  If set to true, then will return all processes not matching the criteria.

• table => obj

  Supply result from object’s . This can be used to reuse the cached result instead of repeatedly call on every invocation.

  See also .

• detail => bool (default: 0)

  Instead of returning just the PID for each result, return a hash (record) of process information instead. Currently this is just the entry from object’s result.

Причины ошибок в файле Proc_cmdline.out

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

Более конкретно, данные ошибки proc_cmdline.out могут быть вызваны следующими причинами:

• Поврежденные ключи реестра Windows, связанные с proc_cmdline.out / SuSE Linux 8.0 Professional.
• Вирус или вредоносное ПО, которые повредили файл proc_cmdline.out или связанные с SuSE Linux 8.0 Professional программные файлы.
• Другая программа злонамеренно или по ошибке удалила файлы, связанные с proc_cmdline.out.
• Другая программа находится в конфликте с SuSE Linux 8.0 Professional и его общими файлами ссылок.
• Поврежденная загрузка или неполная установка программного обеспечения SuSE Linux 8.0 Professional.

/proc/sys/kernel

/proc/sys/kernel/acct

Здесь содержатся три конфигурируемых значения, которые управляют
подсчетом процессов, основанном на свободном пространстве (в процентах)
файловой системы и ведет лог:

1. Если свободное пространство ниже значения в процентах, то
   процесс подсчета останавливается
2. Если свободное пространство выше, то процес запускается
3. Частота в секундах, с которой проверяются предыдущие два
   значения

Чтобы изменить значения в этом файле вам следует использовать
разделенный список параметров.
Default setting: 2 4 30

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

/proc/sys/kernel/ctrl-alt-del

Этот файл содержит двоичное значение, которое управляет тем, как
система реагирует на комбинацию ctrl+alt+delete. Возможны два значения:

1. Ноль (0) значит, что ctrl+alt+delete принимается и
   отправляется программе init. Это позволит выполнить системе мягкую
   остановку и перезагрузку как если бы вы ввели команду shutdown.
2. Один (1) значит, что ctrl+alt+delete не принимается и
   никакого чистого отключения не происходит как если бы вы просто
   выключили питание.

Default setting: 0

/proc/sys/kernel/domainname

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

/proc/sys/kernel/hostname

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

/proc/sys/kernel/msgmax

Здесь определяется максимальный размер сообщения, которое может быть
отправлено от одного процесса другому. Сообщения между процессами в
памяти ядра не копируются на диск, так что если вы увеличите это
значение, то вы увеличите количество памяти используемой операционной
системой.
Default setting: 8192

/proc/sys/kernel/msgmnb

Здесь указывается максимальное количество байт в одном сообщении.
Default setting: 16384

/proc/sys/kernel/msgmni

Здесь указывается максимальное количество идентификаторов сообщений в
очереди.
Default setting: 16

/proc/sys/kernel/panic

Здесь установлено время в секундах, которое ядро будет ждать перед
перезагрузкой если произойдет «kernel panic.» Установка в ноль (0)
секунд отключит возможность перезагрузки при kernel panic.
Default setting: 0

/proc/sys/kernel/printk

Здесь четыре числовых значения, которые определяют куда будут
отправлены сообщения логов, в зависимости от их важности. За более
подробной информацией о различных уровнях логов отправляейтесь в man
syslog(2)

Четыре значения это:

1. Console Log Level: сообщения с высшим приоритетом, чем это
   будут выведены на консоль
2. Default Message Log Level: сообщения без приоритета будут
   напечатаны с этим приоритетом
3. Minimum Console Log Level: минимальное (высочайший
   приоритет) значение, в которое может быть установлен Console Log Level
4. Default Console Log Level: значение по умолчанию для
   Console Log Level

Default setting: 6 4 1 7

/proc/sys/kernel/shmall

Это общее количество разделяемой памяти (в байтах), которое может быть
использовано в системе.
Default setting: 2097152

/proc/sys/kernel/shmax

Здесь указывается наибольший размер сегмента памяти (в байтах)
позволяемый ядром.
Default setting: 33554432

/proc/sys/kernel/shmmni

Этот файл связан с максимальным числом сегментов раздляемой памяти всей
системы.
Default setting: 4096

/proc/sys/kernel/sysrq

Активирует System Request Key, если не равно нулю.
Default setting: 0

/proc/sys/kernel/threads-max

Максимальное число потоков, которое может быть использовано ядром.
Default setting: 2048

Распространенные сообщения об ошибках в Proc_cmdline.out

Наиболее распространенные ошибки proc_cmdline.out, которые могут возникнуть на компьютере под управлением Windows, перечислены ниже:

• «Ошибка в файле Proc_cmdline.out.»
• «Отсутствует файл Proc_cmdline.out.»
• «Proc_cmdline.out не найден.»
• «Не удалось загрузить Proc_cmdline.out.»
• «Не удалось зарегистрировать proc_cmdline.out.»
• «Ошибка выполнения: proc_cmdline.out.»
• «Ошибка загрузки proc_cmdline.out.»

Такие сообщения об ошибках OUT могут появляться в процессе установки программы, когда запущена программа, связанная с proc_cmdline.out (например, SuSE Linux 8.0 Professional), при запуске или завершении работы Windows, или даже при установке операционной системы Windows

Отслеживание момента появления ошибки proc_cmdline.out является важной информацией при устранении проблемы

В погоне за конфигом

то можно было увидеть содержимое переменных окружения PHP, которые были бы полезны для дальнейшего аудита сайта:

• DOCUMENT_ROOT – корень документов сайта;
• SERVER_ADDR – IP-адрес сервера;
• SCRIPT_FILENAME – полный путь до index.php;
• HTTP_USER_AGENT – название агента, с помощью которого юзер браузит по инету;
• HTTP_COOKIE – содержимое передаваемых кукисов и т.п.

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

Не знаю почему, но мне захотелось сделать инклуд PHP-кода через кукисы. Сначала значение кукиcа «ja_purity_tpl», в котором хранилось имя модификации шаблона CMS, был заменено на <? phpinfo(); ?>. После инклуда /proc/self/environ ничего интересного не произошло. Просмотрев содержимое переменной, я обнаружил, что оно по каким-то причинам обрезалось. Изменение значения переменной «__utma» на также не принесло результатов: содержимое и этой переменной опять было обрезано.

После того, как возня с кукисами прекратилась, в дело пошла модификация заголовка user-agent.

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

Посмотрев полный путь до папки сайта на сервере и сформировав полный путь до configuration.php, я, недолго думая, заменил user-agent на команду чтения файла, получилось нечто похожее на это:

А затем заново проинклудил вывод файла /proc/self/environ. Посмотрев внутрь страницы, я обнаружил виновника всего этого торжества – configuration.php.

Naming Hacks

Any string is potentially valid proc name.

RS: «Any string» includes things that look like array elements (but aren’t), with which you can emulate «arrays of function pointers»:

% proc f(1) {} {puts hello}
% proc f(2) {} {puts world}
% proc f(3) {} {puts again}
% for {set i 1} {$i<=3} {incr i} {f($i)}
hello
world
again

And a certain introspection is possible too:

info proc f(*) => f(1) f(2) f(3)

Update 2002-11-15: You don’t have to stop at simulating — you can just have arrays of function pointers!

A proc name that starts with a hash character # can be called by somehow ensuring the # isn’t the first character:

proc #test {} {puts  0]}
\#test ;# -> #test
{#test} ;# -> #test
\x23test;# -> #test
::#test ;# -> ::::#test

Remember that comments are detected prior to the evaluation of a script. # has no importance when commands are being evaluated.