Изпечатай

[rcbandit]

Здравейте,
   Бихте ли могли да ме упътите къде в ядрото мога да намеря source кода на програмата която генерира информацията в /proc. Интересува ме конкретно какви system calls прави програмата за да генерира инфо в /proc

Поздрави

[triel]

https://github.com/torvalds/linux/tree/master/fs/proc

[rcbandit]

благодаря, нещо не намирам това което ми трябва.
Има ли начин да взема натоварването на CPU, RAM, HDD като правя system calls от С демон, без да вземам информацията от /proc?

[gat3way]

Ядрото не вика syscalls за да вземе въпросната информация. Всъщност, викането на syscalls от kernel кода, въпреки че е възможно, е много лоша идея и никой нормален човек няма да те посъветва да го правиш. syscall-а е механизъм, който предоставя на userspace-ския код да влиза в ring0 и да вика някакъв kernel-ски код, а не kernel-а да вика себе си и да проверява доколко въпросните syscall функции са reentrant-ни.

Няма syscall-ове които да ти връщат "натоварването" на CPU-тата.

"Генерирането" на информацията в proc става от страна на kernel кода. Това е виртуална файлова система и четенето от нея "прескача" приятно голяма част от глупостите свързани с vfs слоя. Има си API за това, което е просто за ползване. Регистрираш си няколко callback функции - при четене от обекта и писане в обекта. Единственото усложнение е че трябва да ползваш copy_from_user()/copy_to_user(), поради ред причини, като например че ако върнеш на userspace-ския процес указател към kernel-ска памет, твърде вероятно ще го segfault-неш. Освен което силно те съветвам да не си пишеш kernel module, който да ти връща каквото ти трябва, след като 1) е написано вече и 2) една проверка за дължината на буфера да пропуснеш и отваряш вратичка за local DoS или нещо по-лошо.


И като цяло въобще не виждам смисъла от това. Прекалено бавно изчиташ информацията от procfs??? Искаш да следиш въпросните натоварвания с гранулярност милисекунди? Какъв е смисъла от упражнението?

[rcbandit]

Ядрото не вика syscalls за да вземе въпросната информация. Всъщност, викането на syscalls от kernel кода, въпреки че е възможно, е много лоша идея и никой нормален човек няма да те посъветва да го правиш. syscall-а е механизъм, който предоставя на userspace-ския код да влиза в ring0 и да вика някакъв kernel-ски код, а не kernel-а да вика себе си и да проверява доколко въпросните syscall функции са reentrant-ни.

Няма syscall-ове които да ти връщат "натоварването" на CPU-тата.

"Генерирането" на информацията в proc става от страна на kernel кода. Това е виртуална файлова система и четенето от нея "прескача" приятно голяма част от глупостите свързани с vfs слоя. Има си API за това, което е просто за ползване. Регистрираш си няколко callback функции - при четене от обекта и писане в обекта. Единственото усложнение е че трябва да ползваш copy_from_user()/copy_to_user(), поради ред причини, като например че ако върнеш на userspace-ския процес указател към kernel-ска памет, твърде вероятно ще го segfault-неш. Освен което силно те съветвам да не си пишеш kernel module, който да ти връща каквото ти трябва, след като 1) е написано вече и 2) една проверка за дължината на буфера да пропуснеш и отваряш вратичка за local DoS или нещо по-лошо.


И като цяло въобще не виждам смисъла от това. Прекалено бавно изчиташ информацията от procfs??? Искаш да следиш въпросните натоварвания с гранулярност милисекунди? Какъв е смисъла от упражнението?

Съществува ли друга възможност освен kernel module и /proc?

Целта ми е да правя мониторинг на сървъри. Ето за сега възможностите:
1. Кernel module който да събира данни от таблици в ядрото и daemon да прави запитвания към kernel module за стойностите

Плюсове - покривам всички linux дистрибуции на веднъж
минуси - трудно за писане

2. Да се прави демон който да чете от /proc стойности.
плюсове - най-лесно
минуси - за всяка архитектура proc е различно, някъде липсва proc, някъде не е mounted, за всяка linux дистрибуция и архитектура трябва да се тества, информацията не е пълна, дори с времето може да се промени информацията е него

Нещо важно - ако HDD си замине при решението с proc демона блокира, а да си замине HDD се случва

Мисля че ако трябва да се слагат нещата на кантар kernel module печели ако гледаме в дългосрочен план

[gat3way]

Целта ми е да правя мониторинг на сървъри. Ето за сега възможностите:
1. Кernel module който да събира данни от таблици в ядрото и daemon да прави запитвания към kernel module за стойностите

Плюсове - покривам всички linux дистрибуции на веднъж
минуси - трудно за писане

И твърде вероятно част от информацията няма да ти е достъпна, дори за kernel модула. Не е задължително функциите и структурите от данни да са ти достъпни. Ако пачнеш самото ядро - да, всичко ти е налично. Ако пишеш kernel модул - не, достъпни са ти само изрично export-натите неща. Дали ще успееш да си събереш нужната информация - не знам.

2. Да се прави демон който да чете от /proc стойности.
плюсове - най-лесно
минуси - за всяка архитектура proc е различно, някъде липсва proc, някъде не е mounted, за всяка linux дистрибуция и архитектура трябва да се тества, информацията не е пълна, дори с времето може да се промени информацията е него

Що се отнася до load avg, interrupts, утилизация на памет и т.н. на всяка архитектура нещата са същите и няма разлики.

Да - с времето може да се промени, обаче те уверявам, че kernel-ските API-та се променят още по-често и ще имаш много повече ядове с това.

Ако сървъра няма procfs това е резултат от нечия секюрити параноя предполагам...такива хора заслужават да не може да им се мониторясват машините. Съвсем сериозно, не виждам защо трябва да се покриват всички случаи, включай тези включващи тъпанарски изпълнения на потребителите.

Нещо важно - ако HDD си замине при решението с proc демона блокира, а да си замине HDD се случва

Това пък как го реши? Защо блокира?

Мисля че ако трябва да се слагат нещата на кантар kernel module печели ако гледаме в дългосрочен план

О,да, особено ако си биеш шута след един месец и оставиш някой нещастник да го съпортва в следващите няколко години.

[Neo2SHYAlien]

само за мониторинг един елементарен bash с ps ax да речем не върши ли работа и пак покриваш всички дистрибуции

[rcbandit]

Целта ми е да правя мониторинг на сървъри. Ето за сега възможностите:
1. Кernel module който да събира данни от таблици в ядрото и daemon да прави запитвания към kernel module за стойностите

Плюсове - покривам всички linux дистрибуции на веднъж
минуси - трудно за писане

И твърде вероятно част от информацията няма да ти е достъпна, дори за kernel модула. Не е задължително функциите и структурите от данни да са ти достъпни. Ако пачнеш самото ядро - да, всичко ти е налично. Ако пишеш kernel модул - не, достъпни са ти само изрично export-натите неща. Дали ще успееш да си събереш нужната информация - не знам.

2. Да се прави демон който да чете от /proc стойности.
плюсове - най-лесно
минуси - за всяка архитектура proc е различно, някъде липсва proc, някъде не е mounted, за всяка linux дистрибуция и архитектура трябва да се тества, информацията не е пълна, дори с времето може да се промени информацията е него

Що се отнася до load avg, interrupts, утилизация на памет и т.н. на всяка архитектура нещата са същите и няма разлики.

Да - с времето може да се промени, обаче те уверявам, че kernel-ските API-та се променят още по-често и ще имаш много повече ядове с това.

Ако сървъра няма procfs това е резултат от нечия секюрити параноя предполагам...такива хора заслужават да не може да им се мониторясват машините. Съвсем сериозно, не виждам защо трябва да се покриват всички случаи, включай тези включващи тъпанарски изпълнения на потребителите.

Нещо важно - ако HDD си замине при решението с proc демона блокира, а да си замине HDD се случва

Това пък как го реши? Защо блокира?

Мисля че ако трябва да се слагат нещата на кантар kernel module печели ако гледаме в дългосрочен план

О,да, особено ако си биеш шута след един месец и оставиш някой нещастник да го съпортва в следващите няколко години.

Май ще трябва да се търси друго универсално решение.

п.с
Със скриптове няма как да стане работата.

p.s

Свалих кода на ядрото и намерих в linux-2.6.39/fs/proc директорията кода на /proc който генерира информацията.
Дали ще се получи да взема сорс кода само там където взема например CPU RAM etc. - meminfo.c, cpuinfo.c
И го сложа в kernel module, като модифицирам малко кода да не пише в файл взетите стойности а само стойностите да взема.
Дали ще има проблем с permissions когато модула рови из ядрото да взема данни заедно с оригиналния proc?

[romeo_ninov]

....

Човече, какво толкова искаш да гледаш, защо не си облекчиш живота и не инсталираш nagios с няколко прости чека. То ако тръгнат нещата ако ще и сто модула да си сложил няма да имаш полза