Re: lug-bg: ps ax|grep sth

[George Danchev <danchev@xxxxxxxxx>]

On Sunday 12 June 2005 16:58, Peter Pentchev wrote:
> On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote:
> > Здравейте,

Драсти, 

/* нарочно не съм рязал щото това е като за учебник и e archive-friendly */

> > Имам един въпрос: защо на едната дистрибуция се получава така, че
> > "grep"-a хваща и себе си като процес а на другата не? Проблемът е във
> > версията на grep или трябва някаква донастройка?
>
> По принцип това зависи от много неща - от това колко бързо се изпълнява
> процесът ps и дали шелът изобщо *успява* да пусне grep, преди ps да е
> завършил, през купчина други възможни причини, та чак до начина, по
> който работи scheduler-ът в ядрото.  В крайна сметка се оказва, че дори
> и с трикове от сорта на egrep '[p]rocess' не е много ясно дали винаги ще
> се получи това, което искаш.
>
> Друга причина да не е ясно дали ще се получи това, което искаш, е, че с
> ps | grep на практика винаги има опасност от false positives - други
> процеси, които много, ама много приличат на това, което търсиш, ама не
> са точно това, или просто други процеси, абсолютно несвързани с това,
> което търсиш, които просто съдържат низа, който търсиш, в името на
> програмата или като параметър.  Има няколко начина да се справиш с това:
>
> 1. Пак ps, но доста да стесниш обхвата на търсенето, като например му
> кажеш да показва само process ID-то и името на командата, която се
> изпълнява - без параметри, без потребителско име, без нищо друго.  Под
> FreeBSD и с повечето Linux-ки реализации на ps(1) това става с 'ps axco
> pid,command' - като всъщност важната опция е 'o pid,command'.
> Следващата стъпка е да обясниш на grep да търси *точно* това, което ти
> трябва, а не всичко, което съдържа това, което ти трябва, като някаква
> част от името, например нещо като
>   ps axco pid,command | egrep ' mozilla-bin$'
> или дори
>   ps axco pid,command | awk '$2 == "mozilla-bin" {print $1}'

<допълнение, в случай, че с awk се почувства power disturbance

	Ако ще се филтрува изхода на ps --options може да се вземе и примерното 
решение дадено като psgrep от Perl Cookbook / Глава  1, Низове, Програмата: 
psgrep / достъпен на (и много други работи са достъпни от там):
http://pleac.sourceforge.net/include/perl/ch01/psgrep
http://examples.oreilly.com/perlckbk2/

т.е. може да се правят всевъзможни сечения и/или обединения по всички полета 
от изхода на ps (FLAGS UID PID PPID PRI NICE SIZE RSS WCHAN STAT TTY TIME 
COMMAND) и програмката може да бъде "дописвана on-the-fly", например мачваме  
дума, двоеточие, интервал, дума, интервал, цифра от COMMAND полето с PID > 
1000 за всички простосмъртни:
./psgrep 'command =~ m/\w+:(\s+\w+)\s*\d+/' 'pid > 1000 && uid != 1'
и излавяме
kdeinit: kio_pop3 pop3 /tmp/ksocket.........

накратко: нашите заявки се оценяват през:
eval "sub is_desirable { наша заявка } " .  1 ;
в книгата има други примери, този незнам доколко е смислен де, разбира се може 
да се променя и сорса ако изхода на ps не ни устройва нещо
/>

> 2. Една малка програмка, която се казва 'pidof', и обикновено е част от
> пакет с името sysvinit или, ако не, то нещо като pstools, psmisc или
> нещо такова.  Тя ще ти даде само process ID-тата на всички процеси,
> името на които съвпада *точно* с параметъра, който й подаваш, така че на
> практика прави същото като последните две ps|egrep и ps|awk команди,
> само че по-бързо и по-лесно - и дори е малко по-portable :)
>
> 3. Най-правилният начин: намери някакъв начин да обясниш на процеса,
> който търсиш, че ще е много добра идея той *сам* да си записва process
> ID-то някъде, или намери някакъв друг начин да го контролираш, да го
> пускаш и спираш с някакво инструментче, което следи и помни и знае
> process ID-тата на наследниците си.  За първия вариант - повечето
> daemons имат възможност да стане с нещо като си записват process ID-тата
> във файл, чието име ти си избираш да им укажеш на командния ред.  За
> втория - имам предвид нещо като пакета daemontools и програмката
> supervise в него, която пуска един процес, който *не* преминава във
> фонов режим, и след това можеш да подаваш на supervise команди за това
> какво точно да прави с пуснатия и следен от нея процес.  Много програми
> се поддават на такова отношение - на практика е достатъчно да можеш да
> им обясниш, че не трябва да преминават във фонов режим; sshd -D, squid
> -N, fetchmail -b, ntpd -n и т.н.  Тогава имаш наистина ясен и сигурен
> начин да пращаш сигналчета точно и само на този процес, който те
> интересува.

Понеже можа да се окаже трудно да се влияе на всевъзможни приложения по този 
начин може да се пита и ядрото от /proc/ обхождайки го за число/[stat|exe|
cmdline|...] / разбира се за kernel threads exe ще е празно, за това по-добре 
да се гледа stat за pid (thread) / защото ps и pidof от там вземат тази инфо. 
Според мен това е най-сигурно защото ядрото най-добре пази и знае и абсолютен 
път, и работна директория и т.н. странни неща.

-- 
pub 4096R/0E4BD0AB 2003-03-18 <danchev.fccf.net/key pgp.mit.edu>
fingerprint    1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB