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