RE: lug-bg: ps ax|grep sth

["Vesselin Markov" <vm@xxxxxxxxxxxxxxx>]

Всъщност, май не зависи от времето за изпълнение нито на ps, нито на grep.
Иначе, при всяко положение grep се изпълнява по-бъзо от ps, но за да тръгне
той, ps трябва да е приключил вече.


root@int-proxy:/mnt/localstorage# ps ax | time grep bash
11116 pts/0    Ss     0:01 -bash
10060 pts/2    Ss+    0:00 -bash
27610 pts/0    S+     0:00 time grep bash
27611 pts/0    R+     0:00 grep bash
0.00user 0.00system 0:00.02elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
root@int-proxy:/mnt/localstorage# ps ax | time grep bash
11116 pts/0    Ss     0:01 -bash
10060 pts/2    Ss+    0:00 -bash
27613 pts/0    R+     0:00 -bash
0.00user 0.00system 0:00.00elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
root@int-proxy:/mnt/localstorage# ps ax | time grep bash
11116 pts/0    Rs     0:01 -bash
10060 pts/2    Ss+    0:00 -bash
27657 pts/0    S+     0:00 time grep bash
27658 pts/0    S+     0:00 grep bash
0.00user 0.00system 0:00.00elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+171minor)pagefaults 0swaps
root@int-proxy:/mnt/localstorage# time ps ax | grep bash
11116 pts/0    Ss     0:01 -bash
10060 pts/2    Ss+    0:00 -bash
27693 pts/0    R+     0:00 grep bash

real    0m0.039s
user    0m0.008s
sys     0m0.029s
root@int-proxy:/mnt/localstorage# time ps ax | grep bash
11116 pts/0    Rs     0:01 -bash
10060 pts/2    Ss+    0:00 -bash

real    0m0.051s
user    0m0.015s
sys     0m0.029s



-----Original Message-----
From: owner-lug-bg@xxxxxxxxxxxxxxxxxx
[mailto:owner-lug-bg@xxxxxxxxxxxxxxxxxx] On Behalf Of Peter Pentchev
Sent: Sunday, June 12, 2005 4:58 PM
To: lug-bg@xxxxxxxxxxxxxxxxxx
Subject: Re: lug-bg: ps ax|grep sth

On Fri, Jun 10, 2005 at 11:27:35AM +0300, Ivan Ralenekov wrote:
> Здравейте,
> 
> Имам един въпрос: защо на едната дистрибуция се получава така, че
> "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}'

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 и т.н.  Тогава имаш наистина ясен и сигурен
начин да пращаш сигналчета точно и само на този процес, който те
интересува.

Поздрави,
Петър

-- 
Peter Pentchev	roam@xxxxxxxxxxx    roam@xxxxxxxx    roam@xxxxxxxxxxx
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If there were no counterfactuals, this sentence would not have been
paradoxical.