Amikor elindítunk egy szövegszerkesztőt, nem sok gondunk akad az irányításával, könnyen utasíthatjuk az állományok betöltésére és így tovább. Mindezt azért tehetjük meg, mert a szövegszerkesztő erre lehetőséget biztosít és mivel a szövegszerkesztő egy terminálhoz kapcsolódik. Egyes programok azonban nem úgy lettek kialakítva, hogy állandóan a felhasználó utasításaira támaszkodjanak, ezért az első adandó alkalommal lekapcsolódnak a terminálról. Például egy webszerver egész nap csak webes kéréseket válaszol meg, és általában semmi szüksége nincs a felhasználók utasításaira. A szerverek között leveleket közvetítő programok is ugyanezen osztályba tartoznak.
Ezeket a programokat démononoknak hívjuk. A démonok a görög mitológiában jelentek meg: sem a jót, sem pedig a gonoszt nem képviselték, egyszerű apró szellemecskék voltak, akik az emberiség javát szolgálták, pontosan úgy, ahogy ma teszik azt a különféle web- és levelező szerverek. Ezért is ábrázolták sokáig a BSD kabalafiguráját is egy tornacipős, vasvillás vidám démonként.
A démonként futó programok nevéhez
a hagyományok szerint hozzá szokták
fűzni a "d" betűt. A
BIND a Berkeley Internet Name Domain
(névfeloldó) szolgáltatása, azonban a
hozzá tartozó program neve named,
az Apache webszerver programját
httpd-nek nevezik, a sornyomtató
kezeléséért felelős démon pedig
az lpd és így tovább. Ez
csupán egy hagyomány, megszokás, nem pedig
egy kőbe vésett szabály: például
a Sendmail levelező
démonának neve sendmail és
nem pedig maild.
Néha azért szükségünk lehet
arra, hogy felvegyük valahogy a kapcsolatot a
démonként futó programokkal is. Ennek egyik
lehetséges módja a
jelzések (signal)
küldése (de alapvetően bármilyen
futó programnak küldhetünk). Több
különféle jelzés küldhető
- egyeseknek közülük
megkülönböztetett jelentése van,
másokat magukat az alkalmazások értelmeznek,
amelyről a dokumentációjukban
tájékozódhatunk. A kill(1) vagy
kill(2) paranccsal más tulajdonában levő
futó programoknak nem tudunk jelzéseket
küldeni, ami alól egyedüli kivétel a
root felhasználó.
Bizonyos esetekben a FreeBSD maga is küld néha
jelzéseket. Amikor egy alkalmazást rosszul
programoznak le és megpróbál egy
számára tiltott memóriaterülethez
hozzáférni, a FreeBSD küld neki egy
Segmentation Violation
(SIGSEGV, szegmentálási hiba)
jelzést. Ha egy alkalmazás az alarm(3)
rendszerhíváson keresztül kér egy adott
idő utáni bekövetkező
értesítést, akkor kap erről egy Alarm
(SIGALRM) jelzést és így
tovább.
A folyamatok leállítására
két jelzés használható: a
SIGTERM (befejeztetés) és a
SIGKILL (leállítás). A
SIGTERM a folyamatok
leállításának illedelmes módja,
mivel ekkor a futó program képes
elkapni ezt a jelzést és
észrevenni, hogy le akarjuk állítani.
Ilyenkor a leállítás előtt
lehetősége van szabályosan lezárni a
naplóit és általánosságban
véve befejezni mindent, amit éppen csinál.
Előfordulhat azonban, hogy a folyamatok figyelmen
kívül hagyják a SIGTERM
jelzést, ha például éppen egy
félbeszakíthatatlan feladat közepén
tartanak.
A SIGKILL jelzést azonban egyetlen
futó program sem hagyhatja figyelmen kívül. Ez
lenne a "Nem érdekel, mivel foglalkozol, azonnal
hagyd abba!" jelzés. Amikor
SIGKILL jelzést küldünk egy
folyamatnak, a FreeBSD leállítja a folyamatot ott
és ahol tart
[4].
További használható jelzések:
SIGHUP, SIGUSR1 és
SIGUSR2. Ezek általános
célú jelzések, amelyeket az
alkalmazások eltérő módokon
kezelnek.
Tegyük fel, hogy megváltoztattuk a
webszerverünk beállításait
tartalmazó állományt - valamilyen
módon szeretnénk tudatni a szerverrel, hogy olvassa
be újra a beállításait. Ezt
megtehetjük úgy, hogy leállítjuk
és újraindítjuk a httpd
démont, de ezzel kiesést okozhatunk a szerver
működésében, amit viszont nem
engedhetünk meg. A legtöbb démont úgy
készítették el, hogy a
SIGHUP jelzés hatására
olvassa be újra a beállításait
tartalmazó állományt. Így a
httpd leállítása és
újraindítása helyett egyszerűen
elegendő egy SIGHUP jelzés
küldése. Mivel azonban ez nem
szabványosított, a különböző
démonok ezt a jelzést
többféleképpen is értelmezhetik.
Ezért a használata előtt ennek
mindenképpen járjunk utána a
kérdéses démon
dokumentációjában.
A jelzéseket a kill(1) paranccsal tudjuk elküldeni, ahogy ezt a következő példában is láthatjuk.
Ebben a példában megmutatjuk, hogyan lehet
jelzést küldeni az inetd(8) démonnak.
Az inetd a beállításait
az /etc/inetd.conf
állományban tárolja, és az
inetd a SIGHUP
jelzés hatására képes
újraolvasni ezt.
Keressük meg annak a folyamatnak az
azonosítóját, amelynek a jelzést
kívánjuk küldeni. Ezt a ps(1)
és a grep(1) használatával
tehetjük meg. A grep(1) parancs
segítségével más parancsok
kimenetében tudunk megkeresni egy általunk
megadott szöveget. Ezt a parancsot átlagos
felhasználóként futtatjuk, azonban az
inetd(8) démont a root
birtokolja, ezért az ps(1) használata
során meg kell adnunk az ax
kapcsolókat is.
%ps -ax | grep inetd198 ?? IWs 0:00.00 inetd -wW
Innen kiderül, hogy az inetd(8)
azonosítója 198. Előfordulhat, hogy az
eredményben maga a grep inetd
parancs is megjelenik. Ez a ps(1)
listázási módszere miatt következhet
be.
A jelzés elküldésére
használjuk a kill(1) parancsot. Mivel az
inetd(8) démont a root
felhasználó futtatja, ehhez először a
su(1) parancs kiadásával nekünk is
root felhasználóvá
(rendszeradminisztrátorrá) kell
válnunk.
%suPassword:#/bin/kill -s HUP 198
Ahogy az a legtöbb UNIX(R) esetén elfogadott, a
sikeres végrehajtás esetén a kill(1)
sem válaszol semmit. Amikor viszont nem egy
saját programunknak akarunk jelzést
küldeni, akkor a kill:
PID: Operation not
permitted (a művelet nem
engedélyezett) hibaüzenetet látunk. Ha
véletlenül elgépeltük volna a
futó program azonosítóját, akkor a
küldendő jelzés nem a megfelelő
folyamatnál fog kikötni (ami nem éppen
jó), vagy ha szerencsénk van, akkor a
jelzést egy éppen használaton
kívüli azonosítóra
küldtük. Az utóbbi esetben a
következő láthatjuk: kill:
PID: No such process
(nincs ilyen folyamat).
/bin/kill?: A legtöbb parancsértelmező
beépítetten tartalmazza a saját
kill parancsát, tehát
ilyenkor közvetlenül maga a
parancsértelmező küldi a jelzést,
nem pedig a /bin/kill programon
keresztül. Ez gyakran a javunkra válhat,
azonban a küldhető jelzések megadása
parancsértelmezőnként eltérhet.
Így, ahelyett, hogy egyenként ismernünk
kellene mindegyiket, sokkal egyszerűbb
közvetlenül a /bin/kill
... parancsot
használni.
A többi jelzés küldése is nagyon
hasonló módon történik, hiszen
elegendő csupán a TERM vagy a
KILL behelyettesítése a parancs
megfelelő helyére.
A rendszerünkben óvatosan bánjunk a
futó programok
leállítgatásával, és
legyünk különös tekintettel az 1-es
azonosítóval rendelkező, speciális
feladattal bíró init(8) folyamatra. A
/bin/kill -s KILL 1 parancs
kiadásával ugyanis gyorsan le tudjuk
állítani a rendszerünket.
Mielőtt egy kill(1) parancsot
lezárnánk az Enter
billentyűvel, mindig
győződjünk meg róla, hogy valóban
tényleg a jó paramétereket adtuk
meg.
[4] Ez azért nem teljesen igaz. Van néhány olyan tevékenység, ami nem szakítható meg. Ilyen például az, amikor a program egy másik számítógépen található állományt próbál olvasni, miközben valamilyen ok (kikapcsolás, hálózati hiba) folytán elveszti vele a kapcsolatot. Ekkor a program futása "megszakíthatatlan". Majd amikor a program feladja a próbálkozást (általában két perc után), akkor következik be a tényleges leállítása.
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.