Интернет информационно списание

Типове Linux процеси

Определение за процес е изпълняваща се програма. Докато самата програма с нейните данни се съхранява във файл върху диск и поради тази причина се разглежда като пасивен обект, процесът изпълнява определена работа в системата и е динамичен обект. Той постоянно се променя с изпълнението на инструкциите на програмата от процесора. Освен програма с нейните данни, процесът включва още програмният брояч и всички регистри на процесора, както и стек за съхранение на променливи и междинни данни, като параметри, предавани към подпрограми и адреси за връщане от подпрограми. Една и съща програма може да бъде едновременно изпълнявана от два и повече различни процеса. Процесите са отделни задачи, всеки със своите права и отговорности. Всеки отделен процес се изпълнява в свое собствено виртуално адресно пространство и не може да взаимодейства с други процеси, освен чрез защитен, изцяло управляван от ядрото на системата механизъм. По този начин, ако един процес се срине, той няма да предизвика сриване и на други процеси в системата.
По време на своето съществуване в системата процесът използва множество системни ресурси: процесор за изпълнение на инструкциите, памет за съхранение на програмата и данните, файлове от файловата система и редица физически устройства. Linux разпределя ресурсите между процесите, така че да не се допусне един процес да монополизира процесора или по-голяма част от паметта. Операционната система Linux поддържа два основни типа процеси – нормални процеси и процеси, работещи в реално време. Процесите в реално време имат стриктни ограничения по отношение на времезадръжката за реакция на външни събития.
Нормалните процеси от своя страна се делят на интерактивни, автоматични или пакетни и процеси демони.

Интерактивни процеси

Интерактивните процеси се стартират и управляват от терминала на потребителя. Интерактивните процеси могат да работят в два режима:
режим foreground. До завършване на процеса или превключването му в режим background от терминала не могат да се въвеждат нови команди. Това е нормалният режим на изпълнение на въведена от терминала на потребителя команда или програма;
режим background. След превключване на процеса в този режим от терминала може да се въведе нова команда. В режим  background процесът работи паралелно с процес в режим foreground.
За удобно управление на множество процеси в командните интерпретатори е включен механизмът job control (управление на задачите). С помощта на този механизъм процесите могат да се превключват от режим foreground в background и обратно. Най-често използваните средства на job control са:
Стартиране на процес в режим background. Командите могат да бъдат непосредствено стартирани в режим background, поставяйки знака ‘&’ в края на командния ред: <command> &
Изваждане на процес от режим background. Превключване на процес от background в режим foreground се извършва с командата fg:
fg %n,където n е номер на нужния процес в режим background.
Извеждане на списък на командите, изпълнявани в background – команда jobs;
Спиране на процес, работещ в foreground – Ctrl/Z. Едновременното въвеждане на клавишите Ctrl и Z спира (suspend) изпълнението на процес, работещ във foreground.
Прекъсване и прекратяване на изпълнението на процес, работещ във foreground – Ctrl/C.
1.2.Автоматични процеси
Автоматичните или пакетни процеси (batch processes), не са свързани към терминал. Тези процеси се поместват в опашка тип FIFO, където чакат да бъдат изпълнени. От опашката пакетните процеси се стартират за изпълнение по два различни начина:
Автоматичните процеси се изпълняват на точно определени дата и време, зададени чрез командата аt;
Пакетните процеси се изпълняват при падане на натоварването на системата по премълчaване под 0,8. Тези процеси се въвеждат с командата batch.  Пакетната обработка се използва за оптимизиране на производителността на системата.
1.3.Процеси демони
Демоните (daemons) са сървърни процеси, работещи непрекъснато. Обикновено те се стартират при зареждане на системата и чакат в background режим обръщение към тях от страна на клиентски програми.
2.Състояние на процесите
При своето изпълнение процесите преминават през различни състояния:
Изпълняващ се (Running). Процесът, който текущо се изпълнява (current process).
Готов за изпълнение (Ready).Процесът чака освобождаване на някой от процесорите на системата;
Чакащ (Suspended). Процесът може да чака настъпване на събитие или освобождаване на ресурс. Linux различава два типа чакащи процеси:
Прекъсваеми (Interruptible). Тези процеси могат да бъдат прекъснати от сигнал;
Непрекъсваеми (Uninterruptible). Това са процеси, чакащи за апаратни събития и не могат да бъдат прекъснати при никакви обстоятелства;
Спрян (Stopped). Процесът може да бъде спрян чрез получаване на сигнал;
Зомби (Zombie). Това е завършил процес, за който по редица причини в системата се съхранява определена информация.
Готовите процеси и текущият процес се намират в една и съща опашка, наречена опашка за изпълнение (runqueue) и се наричат общо процеси с възможност за изпълнение (runable processes).
3.Планиране изпълнението на процесите – Диспечеризация
Планирането на изпълнението на процесите се извършва от включеният в ядрото диспечер. Основната задача на диспечера е да разпределя процесите за изпълнение от процесора в еднопроцесорна система или върху процесорите в многопроцесорна система. Той реализира политиката на планиране на системата, която преследва две противоречащи си цели:
минимизация на времето за отговор (response time);
постигане на максимална производителност, изразяваща се в брой обслужени потребителски процеси за единица време.
За постигане на тези цели диспечерът трябва да дава преимущество за изпълнение на най-важните задачи, като при това осигурява справедливост (fairness) при обслужване на процесите. Справедливостта гарантира на всички процеси обслужване в допустим краен интервал от време.
Диспечерът различава два типа процеси:
Ограничени от вход-изход (I/O-bound). Това са процеси, които през по-голямата част от времето си стартират или очакват завършване на входно-изходни операции. Политиката на диспечера за тези процеси е да толерира тяхното изпълнение върху процесора;
Ограничени от процесора (processor-bound). През по-голямата част от времето тези процеси се изпълняват от процесора и издават заявки за входно-изходни операции много рядко. Политиката на диспечера за тези процеси е да ги назначава за изпълнение по-рядко, но за по-дълъг период.
Алгоритъмът на диспечера е базиран на приоритет (priority) между процесите, а обслужването от процесора се базира на времеделение.
4.Приоритет на процесите
Планирането на процесите се извършва на основата на текущия им приоритет. Процесите с по-голям приоритет се изпълняват преди тези с по-малък приоритет. Процесите с еднакъв приоритет се изпълняват един след друг с кръгово подреждане – стратегия round robin. На планиране подлежат само процесите от опашката на готовите процеси (runqueue). В мултипроцесорни системи всеки процесор има своя отделна опашка runqueue.
В Linux се използва концепцията на динамично променящ се приоритет, при която приоритетът на процесите нараства или намалява при тяхното изпълнение в зависимост от поведението им. Всеки процес се създава с начален базов приоритет, който се намалява или увеличава от диспечера. Например динамичният приоритет на ограничените от вход-изход процеси непрекъснато се увеличава, докато приоритетът на ограничените от процесора процеси се намалява
В ядрото на Linux са реализирани два диапазона приоритети:
Приоритети за нормалните процеси;
Приоритети за процесите в реално време.
———————————-
процент използвано време на процесора (%CPU);
процент използвана памет (%MEM);
общо процесорно време, използвано от процеса от момента на неговото стартиране (TIME). С опцията S при извикване на командата top може да се зададе натрупващ режим за изчисляване на времето (CTIME). Времето CTIME включва и процесорното време на завършилите процеси-наследници;
изпълнявана от процеса команда (COMMAND).

Системни извиквания за работа с процеси

1.1.Създаване на процес

Всеки процес се създава като дъщерен процес на съществуващ вече в системата процес-родител. Създаване на процес се осъществява със системното извикване fork():
int pid;
pid = fork();
Създаденият с fork() процес в първия момент е точно копие на своя процес-родител. Двата процеса имат съвършено еднакви код на програма и данни. Породеният процес наследява и всички файлове, с които работи процесът-родител, както и текущата директория. Единствената разлика между двата процеса се състои в значението, което връща системното извикване fork(). Процесът-наследник получава като значение на fork() нула (pid = 0), а процесът-родител – цяло положително число (pid > 0), равно на идентификатора на новия процес. По това значение може да се определи кой процес е наследник и кой родител. Ако fork() не се изпълни по редица причини, се връща значение -1.
1.2.Идентификатори на процесите
Процесът-родител получава идентификатора на създадения от него процес чрез значението, което връща fork(). Собствения си идентификатор процесът може да получи със системното извикване getpid():
int mypid;
mypid = getpid();
Процес може да получи идентификатора на своя процес-родител със системното извикване getppid():
int ppid;
ppid = getppid();
Пример
Процесът може да получи идентификатора на потребителя и на групата със ситемните извиквания:
int uid, gid;
uid = getuid();
gid = getgid();

1.3.Изпълнение на програма
След създаването си с fork() всеки процес изпълнява същата ипотпал програма, както и неговият процес-родител. Със системното извикване exec() на процеса може да се зададе да изпълни друга, предварително компилирана програма. След успешното изпълнение на exec() функционирането на процеса напълно се определя от програмата, чийто изпълним код е поместен в зададения като аргумент на exec() файл. Процесът сменя програмата, но съхранява наследените от процеса-родител отворени файлове и текущата директория, в това число стандартния вход, стандартния изход и стандартния изход за грешка. Ако изпълнението на exec() е неуспешно (зададен е несъществуващ файл или той не съдържа код на програма), то управлението се връща в същата програма, от която е извикано exec().
Системното извикване exec съществува в няколко форми, различаващи се по своите имена и необходимите аргументи:
char *name, *arg0, *arg1, …, *argn;
execl (name, arg0, arg1, …, argn, 0);
Системното извикване execl() обикновено се използва, когато извикваната програма има фиксиран брой аргументи. С аргумента name се задава пълното име на файла с изпълнимата програма, съдържащо пътеката до него. Ако не се зададе пътека, файлът се търси в текущата директория. Аргументът arg0 задава името на файла, а arg1, …, argn задават значението на нужните за работата на програмата аргументи. Списъкът с аргументи завършва с нула.
Пример
execl(“/bin/ls”, “ls”, “-l”, “/home/goro”, 0);
заставя процесът да изпълни командата ls, чийто изпълним файл се намира в директория /bin, която да изведе пълната информация за файловете в директория /home/goro.
1.5.Синхронно и асинхронно изпълнение
След създаване на нов процес процесът-родител и новият процес се изпълняват по премълчаване асинхронно, т.е. те се изпълняват съвършено независимо един спрямо друг. Синхронизиране на изпълнението на родителския процес със завършването на негов наследник може да се осъществи със системното извикване wait(), имащо следния формат:
int pid, status;
pid = wait(&status);
Функционирането на процеса, изпълнил системното извикване wait(), се преустановява до завършване на негов дъщерен процес. След завършване на дъщерен процес процесът-родител се събужда. Като резултат от wait() процесът-родител получава:
идентификатора на завършилия процес – pid. В случай на пораждане на множество процеси, процесът-родител разбира кой точно от тях е завършил;
код на завършване на процеса – status. Най-младшия байт на променливата status се записва системният код на завършване на процеса, който се установява от ядрото на Linux. В съответствие с приетите в UNIX и Linux нулево значение на системния код означава нормално завършване, а ненулево – аварийно завършване. В следващия байт се записва кодът на завършване на дъщерния процес, зададен от него с аргумента на системното извикване exit() – потребителски код на завършване.
Ако процесът няма създадени дъщерни процеси, системното извикване wait(), то той не се преустановява и wait() връща стойност -1. Ако процесът има няколко дъщерни процеса, то wait() трябва да бъде изпълнен толкова пъти, колкото е техният брой.

Система за именоване в Интернет – DNS

DNS е базирана на логическа йерархична дървовидна структура, наречена пространство на имената. Всеки възел от дървото представя DNS име. Коренът на дървото (root) се отбелязва със символа “.”,Всеки възел има име с дължина до 63 символа. Пълното домейн име на всеки възел се формира като последователност от имената по пътя от възела до корена, разделени с точка. Това име е известно под наименованието пълно квалифицирано име на домейн (Fully Qualified Domain Name – FQDN). Имената се записват от повече значимото (името на машината) към по-малко значимото (корена). Съществуват три основни типа домейни от най-високо ниво:Организационни домейни. Това са имена, използващи 3-символни обозначения за указване на основните функции на организациите, принадлежащи на този домейн. Организационните домейни са предназначени предимно за организации в Съединените щати;
Географски домейни. Това са имена, използващи 2-символни обозначения на страна/регион, съобразно ISO 3166;
Обратен домейн. Това е специален домейн под името in-addr.arpa, използван за разрешаването на съответствието IP адрес – име (reverse lookup). Софтуерът, поддържащ информацията за пространството на имената в домейн се нарича сървър на имена (name server).
Сървърите на имена съдържат цялостна информация за част от пространството на имената под името зона (zone). Зоните могат да включват както части от домейн, така и няколко домейна. Разделянето на зони и делегирането позволява ефективно поддържане само на необходимата информация от страна на сървърите на имена. Всеки сървър се явява отговорен (authoritative) за дадена зона и има административни. Сървърите на имена са два основни типа: главни (primary master) и подчинени (slave). Главният сървър на имената за зоната получава данните за нея от файл, намиращ се на машината, където е стартиран. Подчиненият сървър за зоната получава данните за нея от отговорния за същата главен сървър. Този процес е известен под името зонов трансфер (zone transfer).
Когато се направят промени в зоните на главните DNS сървъри, те трябва да се отразят във всички подчинени сървъри за тази зона. Пълният зонов трансфер води до натоварване на мрежовите комуникации, особено при обемни DNS конфигурации. За разрешаването на този проблем в RFC1995 се въвежда специален стандарт на нарастващ зонов трансфер(incremental zone transfer – IXFR). При IXFR само модифицираната част от зоновата информация ще се обменя между сървърите. IXFR функционира до голяма степен като пълния трансфер. Разликата е, че подчиненият сървър изпраща заявка за трансфер от тип IXFR. Главният DNS сървър поддържа информация за последните промени на ресурсните записи. Като отговор той изпраща към подчинения сървър старите и новите версии на записите.

Видове  ресурсни записи. Делегиране на права.

За разрешаването на имената DNS сървърите се консултират със своите зонови файлове. Зоновият файл съдържа ресурсни записи (RR), чрез които се описва информацията в домейна. Описанието на най-използваните RR е направено на базата на препоръчително им подреждане.
Всеки RR има следния формат:
Owner       [TTL]         Class         Type         RDATA
Всяко от полетата съдържа следната информация:
Owner – Името на хоста или домейна, към когото принадлежи съответният RR;
TTL – Интервал от време в секунди, през който DNS сървър ще кешира получената информация. След изтичането му, сървърът трябва да изчисти своя кеш. Може и да не се задава явно;
Class – Дефинира фамилията използвани протоколи. Основно се използва фамилия Интернет протоколи – IN. RFC1034 дефинира и друга фамилия Chaos – CH, използвана експериментално в Масачузетския Технологичен Институт;
Type – Идентифицира типа на RR;
RDATA – Указва данните за съответния тип RR
Ресурсните записи се представят в текстов вид в зоновите файлове. NS записа задава отговорните за указаната зона сървъри. Това могат да са главните и подчинени сървъри за указаната в SOA записа зона, както и сървърите за делегираните зони. За всеки от тези DNS сървъри трябва да има по един ресурсен запис. Всеки зонов файл трябва да съдържа поне един NS ресурсен запис. Ако делегираният сървър е член на същия домейн, необходимо е задаването и на неговия А ресурсен запис, т.н. glue запис. Ако е член на друг домейн, резолверът ще изпълни стандартното разрешаване на имената, за да получи IP адреса на отговорния DNS сървър. Делегиране на права за зоната battle.games.com на DNS сървър ns.battle.games.com  може да се извърши по следния начин:
battle.games.corp.        IN    NS    ns.battle.games.corp.
ns.battle.games.corp.    IN    A    200.100.50.101

Съществуват различни видове ресурсни записи:
A ресурсен запис- Адресният ресурсен запис свързва FQDN с IP адрес;  PTR ресурсен запис – Чрез този тип ресурсен запис се задава обратното съответствие между IP адрес и име.; CNAME ресурсен запис – Този запис създава псевдоним (alias) за указано FQDN (канонично име).; MX ресурсен запис- Ресурсният запис указва пощенски сървър за даденото име на домейн.
18. Конфигуриране на DNS сървъра на имена и клиенти. Конфигурацнонни файлове.
При голяма част от Linux системите услугата за именоване се предоставя от програмата named. Тя е напълно функционален DNS сървър, като в момента е актуална версията BIND9.  Тази реализация поддържа множество нови функционални възможности като:
IPv6;
DNSSec (RFC2535);
динамичен трансфер (RFC2136);
използване на TSIG (RFC2845).
След стартиране на DNS сървъра той прочита своята начална конфигурация от файла /etc/named.conf.
Конфигурационният файл съдържа последователност от оператори чрез които се настройва функционирането на сървъра. Всеки оператор завършва със символа ‘;’. Операторите могат да съдържат блок от свързани с тях опции, указани във фигурни скоби.
Конфигуриране на клиент за използване на имена на хостове
Разрешаването на съответствието име-IP адрес може да се базира на различни схеми под Linux. Един от най-простите начини е използването на статична таблица на хостовете, съхранена във файла /etc/hosts. Типичното му използване е в малки локални мрежи, управлявани от един мрежов администратор и без трафик към външни мрежи.
Този файл съдържа по един запис на ред, всеки от които съдържа от своя страна IP адрес, име на хост и опционно списък от псевдоними (aliases) на този хост.Така се конфигурира За да може клиент да използва услугите на системата за именоване, трябва да се конфигурира специален клиентски софтуер – т.н. resolver. Резолверът може да бъде конфигуриран да открива информацията от файла /etc/host или да ползва услугите на DNS системата, като това се указва във файла /etc/host.conf. Основната опция е order, чрез която се задава последователността в която се извършва достъп до услугите за разрешаване. Валидните операции са допитване го файла hosts (hosts) или до сървър за имена (bind). Ако резолверът ще използва услугите на DNS системата, трябва му да се укаже IP адреса на съответния сървър на имена. Това се извършва в конфигурационния файл /etc/resolv.conf.

Сходни статии:

1. Разпределени и мрежови операционни системи Мрежови операционни системи Към класа на слабо свързаните системи могат да се отнесат мрежовите операционни системи. Те осигуряват среда, посредством която потребител от своя локален PC може да получи достъп до ресурсите на всеки друг отдалечен PC на мрежата. За...
2. Методи за вариантно проектиране на технологичните процеси Методи за вариантно проектиране на технологичните процеси. Системи за класификация и кодиране на обектите. Метод за проектиране на групови и на типови технологични процеси. Видове вариантни процеси: типови технологични процеси (ТП)- разработват се на основата на класификацията на детайлите по...
3. Програмно осигуряване на CAD/CAM системи Програмното осигуряване може да се представи в четири части: базово програмно осигуряване, чиято основна компановка е операционната система; графично програмно осигуряване; база данни и системи за тяхното управление; Приложно програмно осигуряване При Програмно осигуряване на CAD/CAM системата могат да се...
4. Системни екрани на MS Access и Windows Системният екран на ACCESS следва идеологията на MS Windows. Той предоставя набор от графични средства изградени на йерархичен принцип, които условно могат да се представят по зони  инсталирани на екрана Диалогови средства на Microsoft Windows В първата лента на екрана,...
5. Компенсиране на отклонения в положението на изпълнителното звено на робот посредством прецизен MEMS инклинометър Автори: P. Avramov, V. Zamanov Резюме: Настоящата работа представлява изследване върху възможността за използване на прецизен MEMS инклинометър за компенсиране на отклонения в положението на изпълнителното звено, на специализирани роботи, породени от грешки в ставите и еластични деформации в звената...
6. Симулационно моделиране. Изграждане на симулационен модел Симулационно моделиране. Етапи на изграждане на симулационен модел.  Моделиране на технологични производствени системи. Материален поток. Симулационният модел представлява абстрактно описание на изследваната производствена система. Различието на симулационният от реалният експеримент е, че процесът на симулация не с реалната система, а...