Демоните в света на Unix е традиционно по-долу процеси, които не взаимодействат директно с потребителя. В процеса на услуга не е контролният терминал и има съответно потребителски интерфейс. За да контролирате демоните трябва да използват други програми. Името "демони" са възникнали в резултат на факта, че много от процесите на този тип голямата част от времето в очакване на някакво събитие. Когато се случи това събитие, демонът се активира (скокове, като йо-на-кутия), си върши работата и отново заспива, докато чакат за събития. Трябва да се отбележи, че много от демоните, като, например, уеб-сървър или сървър на база данни може да бъде избран от почти всички CPU време, както и други системни ресурси. Тези демони са повече работа, отколкото сън.
Сега ние пропуснете блока ако (argc> 1) на операторите (ние ще се върнете към нея по-късно) и да разгледа основните етапи на демона. BecomeDaemonProcess () функция преобразува нормален процес Linux конзола в процес на демон. ConfigureSignalHandlers () функция настройва сигнални указатели демон процес и BindPassiveSocket () функция, за да отворите определен TCP / IP порт да слуша за входящи заявки. Това е последвано от един цикъл, в който сървърът обработва заявки. Много мрежови сървъри, когато бъдете подканени, създават едно дете процес, за да се справя. По този начин се постига възможност за паралелна обработка на заявки. Някои сървъри се използват за паралелни потоци обработка на заявки. Що се отнася до нашия сървър, с цел опростяване, по който обработва заявките в режим на последователно (блокиране). Ние не очакваме нашата демонстрация на сървъра ще получите много искания, не е тя?
Нормално излизане от заявката цикъл се извършва в процеса на получаване SIGUSER1 сигнал. След излизане на процеса на линия причинява TidyUp () и се затваря. Ние със сигурност може да се завърши демона, като го изпратите на SIGKILL сигнал (SIGTERM и някои други), но сигнал SIGUSER1 потребителското гарантира завършване на нашите приятелски demoga. "Любезен завършване" означава, че сървърът ще отговори на текущата заявка преди края и да го премахнете PID-файл.
Ние правим основната директория на текущата директория на процеса на демон. В процес на започване ни демон може да работи до рестартиране на системата, така че сегашната си diretokriya трябва да принадлежат на файловата система, която не може да бъде демонтиран. Това е последвано от призива lockFD = отворен (lockFileName, O_RDWR | O_CREAT | O_EXCL, 0644);
Всеки процес демон създава т.нар PID-файл (или файл за заключване). Този файл обикновено се намира в директорията / реактивна / тичам и е кръстен daemon.pid, където "демон" е името на демон. Lock файл съдържа процес демон PID стойност. Този файл е важно по две причини. На първо място, тя позволява да се установи наличието на които едно копие на демона вече работи в системата. Повечето демони, включително и нашата, имат vypolnyayatsya не повече от едно копие (това е логично, като се има предвид, че демоните често се обръщат към nonsharable ресурси като мрежови портове). Завършен, на демон процес премахва PID-файл, което показва, че можете да започнете друг процес инстанция. Въпреки това, демонът не винаги завършва нормално, а след това на диска е несъществуваща процес PID-файл. Това би могло да изглежда като непреодолимо препятствие, за да рестартирате демона, но наистина, демоните успешно да се справят с такива ситуации. В процеса на стартиране на демона проверява диск PID-файл с подходящо име. Ако не съществува такъв файл, той чете демон PID стойност и използване на убийството (2) Проверява дали е налице процес с определен PID система. Ако процесът е там, това означава, че потребителят се опита за стартиране на обслужващата отново. В този случай, програмата показва съобщение и изходи. Ако процесът с определения PID е налице, тогава PID-файл принадлежи CRASH демон. В тази ситуация, програмата обикновено съветва потребителя да премахне на PID-файл (отговорност в такива случаи винаги е по-добре да предаде на потребителя) и се опитайте да го стартирате отново. Може, разбира се, също така се случи, че след катастрофата демона ще остане неговата PID-файл на диска, а след това някой друг процес ще получи и същ ИП, че е демон. В тази ситуация отново започва демона ще изглежда така, сякаш копие вече работи в системата, и повторно стартиране на обслужващата не можете. За щастие, на ситуацията, описана е изключително малко вероятно.
Втората причина, че заключващия файл се смята за полезен, е, че с помощта на този файл, можем бързо да разберете PID Демонът, без да се прибягва до командата PS.
Освен това, нашата демон призовава (3) функция вилица, което създава копие от него да обработи. Процесът на майка завършва където:
Това се прави за процеса на демон изключен от контролния терминал. Всеки Unix терминал има набор от технологични групи, наречени на сесията. Във всеки даден момент само един от процесите на групи, принадлежащи на сесията има достъп към терминала (т.е. може да изпълнява вход / изход чрез терминала). Тази група е посочена като на преден план (приоритет). Във всяка сесия, там е процес, един от основателите на която се нарича лидер сесия. Ако процесът на демон се стартира от конзолата, то естествено се превръща в част от приоритетна група от процеси, принадлежащи към съответния терминал сесия.
За да се изключите от терминала, демонът трябва да започне нова сесия, не е свързан с терминал. За да демон може да започне нова сесия, той трябва да бъде лидер на друга сесия. Fork () повикване създава процес дете, което очевидно не е лидер на сесия. На следващо място, процесът на дете се получава чрез разклонението (), започва нова сесия, като се обадите setsid функция (2). Процесът се превърне в лидер (и само член) на нова сесия.
Така че на този етап имаме един процес, който не е свързан с всеки терминал. Освен това, някои насоки препоръчват причина вилица () отново в нов процес е престанал да бъде лидер на новата сесия (лидер System V сесия може автоматично да получи контрол терминал при определени условия). В Linux, отново да се обадя вилица () не е необходимо, и ние няма да направим.
Заслужава да се отбележи, че сега е нашият демон нов PID, ние отново трябва да напиша демон PID-файл. Записваме стойността PID до файла като низ (а не като pid_t тип променлива). Това се прави за удобство на стойност PID на PID-файл може да се прочете от котка. Например:
Нашата демон успя да прекъсне връзката с терминала, от която е стартирана, но тя все още може да бъде свързан с други процеси и файлови системи чрез описания на файлове, наследени от процеса на родител. С цел да се прекъсне тази връзка и ние да затворите всички описания за отваряне на файл в нашия процес:
Функция sysconf () с параметъра _SC_OPEN_MAX връща максималния възможен брой на описания, които могат да се отварят нашата програма. Ние наричаме функцията близо () за всеки дескриптор (независимо дали е отворен или не), с изключение на PID-ЕВРОВОК файл, който трябва да остане отворен.
По време на работа, демона дръжки на стандартния вход, изход, и грешката трябва да бъде отворена, тъй като те са необходими за много функции на стандартната библиотека. В същото време, те deskpritory не трябва да води реална I / O потоци. За да се реши този проблем, ние затваряме първи три дескриптора, а след това ги отвори отново, като посочи името на файла / сътрудничество / нула:
Сега можем да бъдем сигурни, че демонът няма да има повишаване на достъпа до всеки терминал. Въпреки това, демонът трябва да бъде възможно да се установи откъде е изпратено съобщението за тяхната работа. Традиционно, за тази цел, регистрационните файлове (лог-файлове). Регистрационните файлове за демона като черни кутии на самолета. Когато демонът дойде провал, потребителят може да се анализира лог файл, и (с малко късмет), за да се установи причината за неуспеха. Нищо не пречи ни демон, за да отворите свой собствен лог файл, но това не е много удобно. Повечето демони са Syslog комунални услуги, водещи списания редица системни събития. Отваряме достъп до списанието чрез Syslog функция openlog (3):
Функцията първи параметър openlog () - префикса да се добавят към всеки запис в регистъра на системата. Това е последвано от различни Syslog опция. setlogmask (3) функция ви позволява да настроите приоритетни съобщение нива, които са записани в дневника. Когато се обадите функция BecomeDaemonProcess (), минаваме на стойност на параметър logLevel LOG_DEBUG. Във връзка с макро LOG_UPTO това означава, че всички съобщения с приоритет ще бъдат записани в дневника, като се започне с най-висока и завършва LOG_DEBUG.
Последното нещо, което трябва да направим, за "демонизирането" на процеса - за да предизвика setpgrp (функция);
Този призив се създава нов процес група ID, което е идентификатора на текущия процес. В тази работа функция BecomeDaemonProcess () е завършен, тъй като сега ни процес е истински демон.
ConfigureSignalHandlers () функция създава сигнални указатели. Сигналите, които получават нашите демон, могат да бъдат разделени в три групи: игнорирани, "фатален" и обработена. Повикване функцията сигнал (SIGUSR2, SIG_IGN);
Хендлър функция FatalSigHandler () пише за събитието на информация от дневника на приемания сигнал, а след това завършва процеса, като се обадите на тази функция, преди closelog () и TidyUp (), който освободи всички отпуснати процес ресурси:
TermHandler () манипулатор нарича функция TidyUp () и завършва процеса. Хендлър Usr1Handler () прави системен лог запис на учтив края на процеса и присвоява стойността gGracefulShutdown 1 (който, както си спомняте, излиза цикълът за обработка на искането, когато цикълът е готов за него). Процесор HupHandler () сигнал прави запис в дневника на системата, и след това се определя стойността на променливата 1 и gGracefulShutdown gCaughtHupSignal. В реалния живот SIGHUP получаване на сигнала води до рестартиране на демони, които се придружават от повторно четене на конфигурационния файл (който обикновено се чете демон по време на стартиране) и възстановяване на ценностите, съхранявани в него параметри. Необходимостта да прочетете отново конфигурационния файл е най-честата причина рестартиране демони. Нашата конфигурация демон файл не е налице, така че в процеса на рестартиране го направи нищо особено.
Обърнете внимание на вида на променлива и gGracefulShutdown gCaughtHupSignal. При тип sig_atomic_t ние не са се срещали. Използването на този вид гарантира, че четат и пишат на данни в променливи и gGracefulShutdown gCaughtHupSignal бъде изпълнена с атомна, инструкция за процесор, който не може да се прекъсва. Валентност при работа с променливи и gGracefulShutdown gCaughtHupSignal важно potoumu че ги може едновременно да имат достъп и сигнални указатели, както и основната функция на програмата. По същата причина ние етикетират тези променливи ключова дума летливи.
BindPassiveSocket () функция отваря слушане порта на сървъра (в този случай, порт 30333) на всички налични мрежови интерфейси и връща съответния контакт:
Тези, които са прочели статията в тази серия, посветен гнезда трябва да бъдат ясни, което се случва тук. Ние само говорим за една интересна подробност. Ако предишната, вече затворени, контакта, свързан с този порт е в състояние на TIME_WAIT, забавянето е равна на два периода от сегмента на живот (закъснението може да бъде до две минути) може да възникне между затварянето на старите и откриването на нов контакт. За да рестартирате демона, ако ние не трябва да чакаме, ние използваме setsockopt () с SO_REUSEADDR на параметъра.
AcceptConnections () функция ще обработва заявките последователно, като се използва блокиране повикване приемам ():
Това не е най-добрият начин на поведение демон, но ако започнем да се опише обработката паралелния заявка, редакторите не оцеляват. Отчасти на процедира заедно с променлива gGracefulShutdown него се посочва, дали да продължи да обработва заявки програма се нуждае. Ако следващата покана да се свърже () или HandleConnection () се връща съобщение за грешка, тази променлива се на 0 и обработка на заявката се прекратява. Новият гнездото, в резултат на призива приемам (), се предава HandleConnection (функция).
HandleConnection () функция чете низ предава от страна на клиента и след това се връща на клиента. Тогава AcceptConnections () функция затваря връзката открита с покана приемам (). Readline () и WriteToSocket () е тривиално, и да ги третира, ние няма. Ако някъде в AcceptConnections верига повиквания (), HandleConnection (), Readline () и WriteToSocket () се появи грешка, информацията за грешка ще бъде предадена на веригата, докато, докато достигне функцията главната (). В основната функция (), тази информация ще доведат до незабавно прекратяване на демона със съответните вписвания в съобщенията за системните дневници.
Помислете, функция накрая, TidyUp (), който е посочен за много функции на сървъра, преди да го затвори.
TidyUp функция проблем () - "да се отпадъци" за процеса на услуга. В действителност, без тази функция, можете да го направите, след приключване на системата ще се затвори всичките си описания, но правилата на етикета изискват изрично освобождаване на средствата, отпуснати изрично.
Ако компилирате демон с командата
Можете да започнете, екипът на демон
Тъй като демон нуждае от достъп до директорията / реактивна / тичам, тичам, че е необходимо да се корен. Веднага след началото на програмата ще видите командния ред отново, че демоните е напълно нормално. Ако сървърът aahzd извършване на нещо полезно, командата за стартиране е да се регистрирате в един от скриптове стартиране на системата в указателя за /etc/init.d, но ние няма да направи това. След като сървърът работи, можете да дадете командата
В резултат на това се установява връзка със сървъра. Тип на последователност от знаци в конзолата телнет и натиснете "Enter". В отговор на това сървърът връща отпечатан ред и затваря връзката.
Нека сега се върнем към стартовата линия на функция главната (). Въпреки, че ние може да получи PID на демона на своята PID-файл и управление на демона с помощта на командата убийство, този вариант не може да се нарече много удобно. Често се използва за контрол на себе си демон изпълним файл демон, който работи със специални аргументи от командния ред. Нашата демон разбира две команди: стоп (изключване на демон) и рестартиране (рестартиране). Нека да видим как да се държат демон бягане с аргументите на командния ред. В този случай, в началото на програмата на демона се опитва да прочете стойността PID на своята PID-файл. Ако отворите PID-файл не успее, тогава най-вероятно, демона не се изпълнява, както и режима на управление, е просто нищо общо. Ако не се получи стойността PID демона процес мениджър демон изпраща съответния сигнал чрез убийство (функция).
Демоните не са предназначени да преподават никаква информация от страна на потребителя. Собствена информация, която давате на други програми или записани в журналите на система за събития. В следващата статия, ние ще се фокусира върху програми, които се държат по съвсем различен начин и да се разгледа на входа и на изхода на конзолата.
Свързани статии