Статьи Галерея Форум Чат Файлы HowTo Ссылки Поиск
Текущее время: 28 мар 2020, 11:06




Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: статистика из /proc
СообщениеДобавлено: 01 дек 2003, 16:13 
Интересующийся
Аватара пользователя

У нас с: 01.12.2003
Сообщения: 67
Откуда: Минск
Ядро ведет статистику использования процессорного впемени для каждого процесса которую можно прочитать из файла /proc/nnnn/stats.
По сему вопрос - какой формат выводимой инфопмации?


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 01 дек 2003, 20:03 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 30.08.2002
Сообщения: 2339
Откуда: Minsk
/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...


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 02 дек 2003, 16:42 
Интересующийся
Аватара пользователя

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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 02 дек 2003, 16:54 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 30.08.2002
Сообщения: 2339
Откуда: Minsk
да, ведется, иначе как бы ps об этом узнавал? :)
разбирай файлики status и stat

_________________
И увидел я зверя, выходящего из тундры. И число его было 3.14159265358979324...


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 02 дек 2003, 21:58 
Неотъемлемая часть форума
Аватара пользователя

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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 03 дек 2003, 01:01 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 06.02.2002
Сообщения: 9760
Откуда: Менск
ps сдохнет, даже если просто не дать юзверю его читать. это проверялось.

_________________
Опыт растет прямо пропорционально выведенному из строя оборудованию


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 05 дек 2003, 23:23 
На Linux используется так называемый procps.
Это версия ps специально заточенная для /proc.

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


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 06 дек 2003, 01:11 
Неотъемлемая часть форума
Аватара пользователя

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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 20 дек 2003, 12:52 
Интересующийся

У нас с: 19.08.2003
Сообщения: 65
Откуда: Anwerpen, Belgium / Belarus
exe писал(а):
В AIX например есть функция (С), getproctable - она просто
загружает в пользовательский буфер инфу по процессам. И
все. Кернел то все может. Странно что на linux такого не реализовали.


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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 21 дек 2003, 18:36 
Неотъемлемая часть форума
Аватара пользователя

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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 21 дек 2003, 19:07 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 06.02.2002
Сообщения: 9760
Откуда: Менск
exe писал(а):
Есть небольшое преимущество при вызове простой функции -
не нужно о правах думать. А тут нужно писать код который
будет opendir/readdir/closedir делать да ещё с обработкой строк.


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

_________________
Опыт растет прямо пропорционально выведенному из строя оборудованию


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 23 дек 2003, 20:34 
Интересующийся

У нас с: 19.08.2003
Сообщения: 65
Откуда: Anwerpen, Belgium / Belarus
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.)


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 23 дек 2003, 21:11 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 06.02.2002
Сообщения: 9760
Откуда: Менск
dimm_coder писал(а):
В ядре есть возможность проверить от имени какого пользователя был сделан некоторый сис. вызов. См. capable() + уровни привилегий на выполнение различных классов действий...
Так работаю многие сис. вызовы (снова же можно поискать в исходниках).


Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.

_________________
Опыт растет прямо пропорционально выведенному из строя оборудованию


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 23 дек 2003, 23:02 
Интересующийся

У нас с: 19.08.2003
Сообщения: 65
Откуда: Anwerpen, Belgium / Belarus
Llama писал(а):
dimm_coder писал(а):
Нет, не то. BSD можно, насколько я помню, можно указать, какую функцию какой именно пользователь может заюзать, или что-то типа того.


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


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: 24 дек 2003, 00:29 
Неотъемлемая часть форума
Аватара пользователя

У нас с: 06.02.2002
Сообщения: 9760
Откуда: Менск
ГМ, насколько я помню 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-Открывать файл для записи.

_________________
Опыт растет прямо пропорционально выведенному из строя оборудованию


Вернуться к началу
 Не в сети Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.


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

Найти:
Перейти:  
[ All resources are available under GNU GPL ] [ Support ] [ Hosted by DataHata | MyCloud.by ] [ Powered by phpBB® Forum Software © phpBB Group ]

LVEE Winter LVEE Rambler's Top100