статистика из /proc

Все о программировании под *nix
Аватара пользователя
imp3
Интересующийся
Сообщения: 67
Зарегистрирован: 01 дек 2003, 16:06
Откуда: Минск

статистика из /proc

Сообщение imp3 »

Ядро ведет статистику использования процессорного впемени для каждого процесса которую можно прочитать из файла /proc/nnnn/stats.
По сему вопрос - какой формат выводимой инфопмации?

Аватара пользователя
mend0za
Неотъемлемая часть форума
Сообщения: 2332
Зарегистрирован: 30 авг 2002, 12:33
Откуда: Minsk

Сообщение mend0za »

/usr/share/doc/kernel-doc-*/Documentation/filesystems/proc.txt.gz
или <kernel-source>/Documentation/filesystems/proc.txt в помощь.

Только у себя на машине и в доках не вижу такого файла stats, есть stat, statm, status. А whois mr. Stats ? :)
И увидел я зверя, выходящего из тундры. И число его было 3.14159265358979324...

Аватара пользователя
imp3
Интересующийся
Сообщения: 67
Зарегистрирован: 01 дек 2003, 16:06
Откуда: Минск

Сообщение imp3 »

Да-с stats это у меня гибрид status и stat :oops:
Мне нужно узнать :общее время работы процесса и % нахождения его в режиме user/kernell. Ведется ли вообще ядром такая статистика?

Аватара пользователя
mend0za
Неотъемлемая часть форума
Сообщения: 2332
Зарегистрирован: 30 авг 2002, 12:33
Откуда: Minsk

Сообщение mend0za »

да, ведется, иначе как бы ps об этом узнавал? :)
разбирай файлики status и stat
И увидел я зверя, выходящего из тундры. И число его было 3.14159265358979324...

Аватара пользователя
exe
Неотъемлемая часть форума
Сообщения: 860
Зарегистрирован: 28 ноя 2003, 21:08
Откуда: Минск

Сообщение exe »

А что на linuxe ps использует /proc ? Нехорошо как-то.
Если я kernel перестрою и /proc запрещу (а можно ли это?),
как ps то выживет?

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

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

Anonymous

Сообщение Anonymous »

На Linux используется так называемый procps.
Это версия ps специально заточенная для /proc.

Вообще ничего плохого в том что ps использует /proc нету.
уж лучше работать через procfs чем давать право на чтение /dev/kmem или /dev/mem каждой программе сбора системной статистики (через всякие suid'ные дела). Хотя, конечно, могли бы для этого дела внедрить какойнить sysctl (как, например, сделано в FreeBSD)... Но если всё хорошее копировать с BSD, то оригинальности у линукса не останется :)

Аватара пользователя
exe
Неотъемлемая часть форума
Сообщения: 860
Зарегистрирован: 28 ноя 2003, 21:08
Откуда: Минск

Сообщение exe »

В AIX например есть функция (С), getproctable - она просто
загружает в пользовательский буфер инфу по процессам. И
все. Кернел то все может. Странно что на linux такого не реализовали.

dimm_coder
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

exe писал(а):В AIX например есть функция (С), getproctable - она просто
загружает в пользовательский буфер инфу по процессам. И
все. Кернел то все может. Странно что на linux такого не реализовали.
А в Linux есть /proc fs, который предназначен для экспорта сис информации ядра в "пользовательский" мир. Который в общем и не является fs как в обычном понимании дисковых fs.
Зачем дублировать существующую ф-ность/идеологию новым сис вызовом ядра?
Причем этот вызов был бы не сложным по реализации но довольно большой по объему + куча флагов ввести для определения различного типа информации (NtQuerySystemInformation() в NT можно посмотреть).
Если уж очень хочется, не обязательно вводить новый вызов - можно написать простенький драйвер симв устр., который или по ioctl() запросу или просто расширяет /proc своими экспортируемыми "файлами" и возвращать из ядра все что заблагорассудится. Например, из /proc/ext/ps_id - возвращать id процессов с нек доп. инфой.

Аватара пользователя
exe
Неотъемлемая часть форума
Сообщения: 860
Зарегистрирован: 28 ноя 2003, 21:08
Откуда: Минск

Сообщение exe »

Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.
А ещё если формат изменят, или конфигурацию ядра. Интересно
а ftw/nftw() по /proc отработает? Надо будет проверить как
только время появится

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

exe писал(а):Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.
Это не есть гут. Так, если мне не хочется - я просто отберу права на /proc и и фиг он туда посмотрит... В случае с функциями ядра придется разбираться, как юзверю запустить выполнение именно этой функции... В BSD с этим проще, а вот линух (по крайней мере vanilla kernel) это делать не умеет. Прикрчивать в дистрибутив патчи типа RSBAC или NSA SE Linus - то еще удовольствие...
Опыт растет прямо пропорционально выведенному из строя оборудованию

dimm_coder
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

exe писал(а): Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.
А ещё если формат изменят, или конфигурацию ядра. Интересно
а ftw/nftw() по /proc отработает? Надо будет проверить как
только время появится
Llama писал(а): В случае с функциями ядра придется разбираться, как юзверю запустить выполнение именно этой функции... В BSD с этим проще, а вот линух (по крайней мере vanilla kernel) это делать не умеет. Прикрчивать в дистрибутив патчи типа RSBAC или NSA SE Linus - то еще удовольствие...
В ядре есть возможность проверить от имени какого пользователя был сделан некоторый сис. вызов. См. capable() + уровни привилегий на выполнение различных классов действий...
Так работаю многие сис. вызовы (снова же можно поискать в исходниках).

При считывании параметров через /proc не происходит обращение к диску за данными - это всего-лишь "интерфейс" к данным ядра, а не файлы в обычном понимании.
Единственное преимущество отдельного вызова - в том что он 1 и нет множества переключений в режим ядра и обратно как при аналогичном множественном считывании из /proc.
Недостаток - этот вызов будет слишком "большим" чтобы иметь возможность экспортировать ту же информацию что и /proc. Конечно, можно рассмотреть ряд оптимизаций (как кеширование списка параметров ядра для получения за один вызов). Хотя вряд ли это стоит выделки, не думаю что найдется много программ, которым необходима множественная инф из /proc (как ps), и что они так уж хромают производительностью.
(В любом случае концепция /proc мне кажется довольно удобной нежели сис. вызов для получения инфы, как это есть в винде. Даже для пользователя это выглядит как _вызовы_ , вообще там даже нет единого интерфейса получения списка процессов для 9x и NT.)

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

dimm_coder писал(а): В ядре есть возможность проверить от имени какого пользователя был сделан некоторый сис. вызов. См. capable() + уровни привилегий на выполнение различных классов действий...
Так работаю многие сис. вызовы (снова же можно поискать в исходниках).
Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.
Опыт растет прямо пропорционально выведенному из строя оборудованию

dimm_coder
Интересующийся
Сообщения: 65
Зарегистрирован: 19 авг 2003, 10:56
Откуда: Anwerpen, Belgium / Belarus
Контактная информация:

Сообщение dimm_coder »

Llama писал(а):
dimm_coder писал(а): Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.
Имеешь в виду настроить права вызова сис. вызовов администратору для пользователей?
Никогда не слышал, хотя можно и уточнить конечно.
В Linux с точки зрения ядра пользователь (скорее даже процесс с его провами) принадлежит к некоторым группам, которые имееют определенные права работы в режиме ядра. Раньше это было просто деление: root или нет. Начиная с 2.1 (насколько я помню) - введены более широкие классы.

Аватара пользователя
Llama
Неотъемлемая часть форума
Сообщения: 9749
Зарегистрирован: 06 фев 2002, 11:40
Откуда: Менск

Сообщение Llama »

ГМ, насколько я помню RSBAC и NSA SE Linux - позволяют делать что-то подобное... Вот то, что им можо контролировать...

ADD_TO_KERNEL -Добавлять модуль в ядро (для драйвера)
ALTER - Изменить контрольную информацию для IPC
APPEND_OPEN -Открытие для добавления
CHANGE_GROUP-Сменить группу
CHANGE_OWNER -Сменить Владельца
CHDIR-Сменить Каталог
CLONE-Клонировать процесс
CLOSE-Запрос на закрытие
CREATE-Запрос на создание
DELETE-Запрос на удаление
EXECUTE-Запрос на запуск
GET_PERMISSIONS_DATA-Прочитать права UNIX.
GET_STATUS_DATA- Получить информацию о файле ( вызов stat() ).
LINK_HARD-Сделать жесткую ссылку
MODIFY_ACCESS_DATA -Модифицировать информацию о времене доступа к файлу
MODIFY_ATTRIBUTE-Изменить аттрибут rsbac
MODIFY_PERMISSIONS_DATA- Изменить права Unix.
MODIFY_SYSTEM_DATA- Изменить системные данные.
MOUNT-Совершить операцию монтирования
READ-Произвести чтение.
READ_ATTRIBUTE- Произвести чтение аттрибута RSBAC.
READ_OPEN- Открыть файл для чтения.
READ_WRITE_OPEN- Открыть файл для чтения-записи.
REMOVE_FROM_KERNEL- Удалить модуль из ядра (для драйверов)
RENAME-Переименовать
SEARCH-Произволить поиск.
SEND_SIGNAL-Посылать сигнал дркгим процессам.
SHUTDOWN-Выключать/Перезагружать систему.
SWITCH_LOG-изменять параметры протоколирования RSBAC.
SWITCH_MODULE-Включать/Выключать модули.
TERMINATE- Останавливать процесс.
TRACE- Трессировать процесс.
TRUNCATE-Усекать файл
UMOUNT-Выполнять демонтирование.
WRITE-Производить запись
WRITE_OPEN-Открывать файл для записи.
Опыт растет прямо пропорционально выведенному из строя оборудованию

Ответить