8. Programok futtatása¶
A programok kezelése az operációs rendszerek egyik legfontosabb feladata, ehhez a témakörhöz nagy ismerethalmaz és számos parancs tartozik. Ebben a fejezetben ezeket tekintjük át, elsősorban a gyakorlati szempontokra koncentrálva.
Egy program indítása a gyakorlatban nagyon egyszerű, a parancssorba be kell írni annak nevét. A legtöbb program ennek hatására el is indul, de bizonyosak nem — esetükben azokat a teljes elérési úttal együtt kell megadni. (Az előbbi egy kiegészítő mechanizmus eredménye, az elvét mindjárt megmutatom, de először nézzük az általános esetet!) Az alábbi példában a /usr/games
könyvtárban levő ninvaders
nevű konzolon futó játékprogramot indítom el, ehhez a program nevét a teljes elérési úttal együtt írom le:
feri@columbo:~$ /usr/games/ninvaders
Izgalmas, így néz ki, ha eluntad, a Ctrl-C lenyomásával megszakíthatod a futását:
.-..-..-..-..-..-..-..-..-..-.
-O_-O_-O_-O_-O_-O_-O_-O_-O_-O_
-O_-O_-O_-O_-O_-O_-O_-O_-O_-O_
/o\/o\/o\/o\/o\/o\/o\/o\/o\/o\
/o\/o\/o\/o\/o\/o\/o\/o\/o\/o\
### ### ### ###
##### ##### #### #####
####### ####### ####### #######
## ## ## ## ## ## ## ##
/-^-\
Level: 01 Score: 0000000 Lives: /-\ /-\
Ha az aktuális könyvtárban levő program indítása a célod, az elérési út meghatározására a . karaktert kell használni (korábban már tárgyaltuk, hogy a . karakter az aktuális könyvtárat jelenti). Az előbbi példában, ha a /usr/games
könyvtárban vagy, a program indítása így történik:
feri@columbo:/usr/games$ ./ninvaders
8.1. A PATH környezeti változó¶
A gyakorlatban eléggé kellemetlen lenne mindig legépelni az elindítani kívánt programot tartalmazó könyvtár nevét is – ha az ls helyett mindig /bin/ls parancsot kellene írni, hamar elgondolkodnánk azon, hogyan lehetne ezen egyszerűsíteni. Egy jól beállított rendszer esetén ez így is van, a legtöbb program elindul a könyvtár meghatározása nélkül is. Az alábbi példában látható, hogy a ninvaders futtatásához elég csak a nevét begépelni:
feri@columbo:~$ ninvaders
Mielőtt megmutatom, hogy ez miért van így, gondoljuk végig azt a kérdést, hogy hol keresse a parancsértelmező az elindítandó programot, ha annak a nevét elérési út nélkül adja meg a felhasználó? A gyakorló szerverünk, a columbo.uni-eszterhazy.hu többé-kevésbé csak egy alaprendszert tartalmaz, ennek ellenére e sorok írásakor 24.724 könyvtár van a diszken (egy kis szűrési gyakorlat: find / -type d | wc -l). Az nem lenne ésszerű megoldás, hogy bármelyik program indításkor az összeset nézze át a rendszer, mindegyikben keresve a programfájlt. (Nem mellesleg ez a rendszer biztonságát is aláásná, mivel semmi sem akadályozza a felhasználókat abban, hogy a rendszer parancsaival azonos nevű programokat a saját könyvtáraikba helyezzenek és kiügyeskedjék, hogy a rendszer parancsai helyett mások azokat futtassák.) A megoldást az jelenti, hogy a rendszer programjait meghatározott könyvtárakban kell elhelyezni, és a parancsértelmező ezekben fogja azt keresni. Néhány tipikus példa ezekre a könyvtárakra:
/usr/bin
: az általános felhasználók számára használható programok. (A bin jelentése: binárisok.)/usr/sbin
: csak a rendszergazda számára elérhető programok. (Az s jelentése: superuser.)/bin
és a/sbin
: a rendszer indulása során az különböző futási szintekre kerül, de egy sérült rendszer javítása során egy alacsonyabb szinten kell azt megállítani. Ebben az üzemmódban nem biztos, hogy az/usr
könyvtár már mountolva van, ezért a rendszer karbantartásához leginkább szükséges programokat (ilyen pl. a mount), a gyökér fájlrendszerben kell elhelyezni. Ezek a/bin
és az/sbin
az/usr/bin
és az/usr/sbin
helyett. (Egyes rendszerekben, pl. a RedHat Linuxban nincs ilyen szétválasztás, ezek a könyvtárak valójában csak linkek)./usr/local/bin
: ez az egyedi programok helye, azoké, amelyeket a rendszergazda írt, vagy másolt a rendszerbe és minden felhasználó számára elérhetővé szeretné tenni. Nem lenne szerencsés, ha ezeket a fenti könyvtárak valamelyikébe ömlesztenék bele, mert összekeverednének a rendszerrel települt programokkal, egy esetleges újratelepítés előtt körülményes lenne kiválogatni őket a rendszerrel érkezett programok közül. Hasonló célja van a/usr/local/sbin
könyvtárnak is, itt azok a programok vannak, amelyek nem az operációs rendszerrel kerültek telepítésre, de csak a rendszergazda futtathatja őket./usr/games
és a/usr/local/games
könyvtárak a játékprogramok ajánlott helyei.
A rendszer rugalmassága érdekében ezek a könyvtárak nincsenek „bedrótozva” a rendszerbe, hanem egy PATH
nevű környezeti változó tartalmazza ezeket, a változó értékének módosításával ezt kedvedre módosíthatod.
Megjegyzés
A környezeti változókra gondolj úgy, mint a programod változóira, de ezeket a parancssoros környezetben használhatod, adhatsz értékeket nekik, illetve használhatod fel azt. Az alábbi példában a NEV nevű változónak értéket adok, majd a echo paranccsal meg is jelenítem azt:
feri@columbo:~$ NEV="Szabó Lajos" feri@columbo:~$ echo $NEV Szabó Lajos
A programok indítási helyeinek leírására szolgáló környezeti változó neve PATH
, az értékét pedig az echo $PATH paranccsal tudod megjeleníteni:
feri@columbo:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
A példában látható, hogy az egyes könyvtárak kettősponttal vannak elválasztva egymástól, és ezek határozzák meg a keresésben szereplő könyvtárakat.
A root esetében a PATH
változó értéke más, tartalmazni fogja az /sbin
, az /usr/sbin
és az /usr/local/sbin
könyvtárakat, ugyanakkor nem lesznek benne a játékok helyei. Ennek az az oka, hogy rendszergazdaként csak azokat a feladatokat érdemes végezni a rendszerben, amelyhez valóban korlátlan jogosultsági kör szükséges, és a játékprogramok nem tartoznak ezek közé. (Egy másik lehetséges ok az, hogy a rendszergazdák mind mogorvák és sosem játszanak — bár ez utóbbi nem valószínű.)
root@columbo:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Megjegyzés
A
PATH
környezeti változó értéke a bejelentkezéskor állítódik be. Ez egy többlépéses folyamat, ennek első állomása a/etc/environment
tartalmának beolvasása. A legtöbb esetben ez tartalmaz egy beállítást aPATH
-ra vonatkozóan, amely minden felhasználóra érvényes lesz. Ha ezt bizonyos felhasználók esetében módosítani kellene, a saját könyvtárukban levő.profile
fájlba írtak módosításával lehetne megtenni. Ez a fájl minden felhasználó home könyvtárában jelen van, és az abban levő parancsok a bejelentkezést követően automatikusan lefutnak.Aránylag ritkán használt, de bizonyos esetekben nagyon hasznos parancs a timeout, amivel megakadályozhatod, hogy egy parancs túl sokáig fusson. Két paramétert vár, az egyik a maximális futási idő, a másik pedig a futtatandó program. A timeout 10 ninvaders a játékprogramot csak 10 másodpercig engedi futtatni, annak eltelte után megszakítja. Fontos, hogy egy program futási idejének ilyen módon történő korlátozása veszélyes lehet abban az esetben, ha a program megszakítása nem várt mellékhatással jár, pl. a részben feldolgozott adatok elvesztését okozza.
8.2. A prioritásról¶
Egyes programok esetében szükség lehet arra, hogy azok magasabb prioritással fussanak, hogy a rendszer számukra több működési időt biztosítson, mint másoknak. A Unixok a prioritás meghatározására két parancsot biztosítanak, ezek a nice és a renice. A nice használatához meg kell adni a prioritás mértékét, valamint a program nevét. A mértéket egy viszonyszám fejezi ki, értéke -20 és +20 közé eshet, minél nagyobb, (figyelj!) annál alacsonyabb prioritással fut majd a programod. Ráadásul a negatív értékek csak a rendszergazda számára használhatók, így igazán magas prioritást csak ő állíthat be. Ebben a példában a játékprogram a legalacsonyabb prioritással fut:
feri@columbo:~$ nice 20 ninvaders
Egy már futó program prioritásának megváltoztatása a renice paranccsal történik. Az egyik paraméter az új prioritás érték, a másik viszont nem lehet a program neve, mert egy időben több felhasználó is futtathatja ugyanazt a programot, így a név nem elég az azonosításhoz. A program neve helyett ezért a futó példány belső azonosítóját, az ún. process id-t kell megadni. Erről részletesen a Processzkezelés c. fejezetben lesz szó, addig fogadd el, hogy az alábbi példában a ninvaders futó példányát a 785-ös szám azonosította.
feri@columbo:~$ renice 0 785
785 (process ID) old priority 20, new priority 0
A renice parancs értelemszerűen csak az általad indított programok esetében működik, másokét nem tudod módosítani. A rendszergazdára értelemszerűen nem vonatkozik ilyen korlátozás, ő bármelyik futó program prioritását módosíthatja.
8.3. Álnevek¶
A programok indításának egyszerűsítését szolgálják az álnevek, amelyek az alias paranccsal kezelhetők. Ezt a bash parancsértelmezőjében más, eddig tanult parancsoktól eltérően nem külső programokkal valósították meg, hanem magába a shellbe építették be. Az alias arra jó, hogy bonyolultabb parancsok beírását egyszerűsítse le. Ha például gyakran használod az ls -CF parancsot, és ezt egy rövidebb névvel, egy l begépelésével szeretnéd elérni, először létre kell hoznod egy aliast így:
root@columbo:~# alias l='ls -CF'
Az alias parancs után egy értékadást kell leírni. Ennek bal oldalán a létrehozandó rövid név szerepel, a jobbon pedig az ennek használatakor végrehajtandó parancsnak kell állnia. A alias l='ls -CF’ egy ilyen értékadás, ennek végrehajtása után az l begépelése az ls -CF parancsnak felel majd meg. Fontos, hogy értsd: az alias csak az értékadást végzi el, amit csak egyszer kell begépelned, ennek hatása a továbbiakban már megmarad.
Az alábbi három példa valódi, a home könyvtáram .bashrc
fájljából szűrtem ki őket. A shell a sikeres bejelentkezést követően ennek tartalmát is le fogja futtatni. Mivel ez akár felhasználónként különböző lehet, ezzel a munkakörnyezet mindenki számára egyénre szabva állítható be.
feri@columbo:~$ cat .bashrc | grep ^alias | grep ls
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls —color=auto'
Megjegyzés
A fenti példában az ls parancsot egy ls nevű aliasra cseréltük, tehát arra is lehetőség van, hogy egy alias neve megegyezzen egy már létező parancséval. Mivel a parancsértelmező először az aliasok közt keresi a végrehajtandó programot, ezért az eredeti parancs helyett mindig az alias fog indulni, így példánkban a tartalomjegyzék mindig színes lesz. Amennyiben az aliasok közti keresést szeretnéd kihagyni, és az eredeti parancsot szeretnéd futtatni, a ` karaktert kell használnod. A fenti példa alapján a :command:ls` parancs nem fog színes tartalomjegyzéket megjeleníteni, mert ennek hatására nem az alias, hanem a ls parancs indul el.
8.4. Programok futtatása a háttérben¶
Egy hosszan futó program esetében kellemetlen lenne csak ülni, és várni, hogy végre lefusson. Szerencsére a modern operációs rendszerek lehetővé teszik, hogy egy programot a háttérben futtassunk. Lássuk, milyen parancsokat biztosítanak a Unix rendszerek ehhez!
8.4.1. Az &¶
A legrégebbi módszer nagyon egyszerű, bármely parancs végére gépelt & karakter hatására annak futása a háttérben folytatódik. Ebben a példában egy igen hosszan futó programot indítunk a háttérben:
feri@columbo:~$ ./lottoszamok &
[1] 29395
feri@columbo:~$
A parancs kiadása után megjelenik a háttérben futó program azonosítója, és a prompt. A parancsértelmező újabb parancsokat fogad, miközben a lottószámok számolása a háttérben folytatódik.
Az ilyen módon háttérben futó programok kimenete és hibaüzenetei továbbra is a standard outputra kerülnek. Ez nem feltétlenül szerencsés, mert a később elindított programok képernyőképét felül fogják írni. Ezért ilyen esetben feltétlenül ajánlott a kimenet és a hibák fájlba történő átirányítása.
feri@columbo:~$ ./lottoszamok >kimenet.txt 2>hibak.txt &
[1] 29395
feri@columbo:~$
Ha a programot ismét az előtérbe akarod hozni, az fg parancsot kell használnod:
feri@columbo:~$ fg
./lottoszamok
Megjegyzés
Ha több programot is indítottál a háttérben, az fg ezeket sorban fogja előtérbe hozni. Ha ettől el akarsz térni, az fg paramétereként meg kell adnod a program sorszámát pl. így: fg 2.
Ha egy programot nem háttérben indítottál, utólag is „odaküldheted” a Ctrl-Z megnyomásával. Szükség esetén előtérbe hozni szintén az fg használatával lehet.
8.4.2. A nohup¶
Ha kilépsz a shellből, a fenti módon módon indított programok futása is véget ér. Ha azt szeretnéd, hogy ez ne így történjen, használd a nohup parancsot (NO HangUP) így:
feri@columbo:~$ nohup ./lottoszamok &
[3] 29589
nohup: bemenet figyelmen kívül hagyása és kimenet hozzáfűzése a következőhöz: "nohup.out"
feri@columbo:~$
A nohup a programok kimenetét alapértelmezésben a nohup.out
fájlba irányítja, így az esetleges üzenetek, eredmények a fájl tartalmát kiolvasva elérhetők.
8.4.3. A screen¶
Egy másik lehetőség a programok háttérben futtatására a screen parancs használata. Ezt elindítva egy háttérben futó, új parancsértelemezőt kapsz, amely a kijelentkezésed után is működni tud. (Egy tájékoztató képernyőt követően egy Enter vagy Space gombot kell nyomnod, hogy továbblépj.
feri@columbo:~$ screen
Screen version 4.01.00devel (GNU) 2-May-06
Copyright (c) 2010 Juergen Weigert, Sadrul Habib Chowdhury
Copyright (c) 2008, 2009 Juergen Weigert, Michael Schroeder, Micah Cowan, Sadrul Habib Chowdhury
Copyright (c) 1993-2002, 2003, 2005, 2006, 2007 Juergen Weigert, Michael Schroeder
Copyright (c) 1987 Oliver Laumann
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program (see the file COPYING); if not, see http://www.gnu.org/licenses/, or contact Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA.
Send bugreports, fixes, enhancements, t-shirts, money, beer & pizza to screen-devel@gnu.org
Capabilities:
+copy +remote-detach +power-detach +multi-attach +multi-user +font +color-256 +utf8 +rxvt +builtin-telnet
[Press Space or Return to end.]
A screen környezetéből két módon tudsz kilépni, a Ctrl-A után a d megnyomásával a parancsértelmező a háttérben fut tovább, de a kapcsolat megszakad vele. A másik lehetőség a screen eldobása, ezt a már korábban megszokott exit paranccsal vagy a Ctrl-d billentyűkombinációval tudod megtenni (ezzel kilépsz a screen shelljéből).
feri@columbo:~$ [Ctrl-A] [d]
[detached from 31823.pts-3.columbo]
Egy újabb bejelentkezést követően a screen -r paranccsal tudsz visszatérni ebbe a shellbe és ott folytatni a munkádat, ahol abbahagytad. Amennyiben több screen folyamatot indítottál el, a visszatéréshez meg kell adnod a kívánt folyamat azonosító számát, a lehetséges értékeket a program megjeleníti.
feri@columbo:~$ screen -r
There are several suitable screens on:
31823.pts-3.columbo (2018-11-25 17.11.23) (Detached)
755.pts-0.columbo (2018-10-16 08.45.44) (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.
A fenti környezetben a 31823-as azonosítójú screenhez a scren -r 31823 paranccsal térhetsz vissza.
Megjegyzés
Minden esetben használom a screen parancsot, ha a futtatott program megszakadása problémát jelenthet. Sosem mulasztom el a rendszer frissítésekor, mely félállapotban maradhat akkor, ha a folyamat során megszakad az internet kapcsolat. A megszakadó frissítések után a rendszer helyrehozása nem mindig egyszerű, és a screen használatával könnyen elkerülhető.
8.5. Futtatás más felhasználóként¶
A rendszer használata során a rendszergazdásnak és a felhasználóknak is szükségük lehet arra, hogy rövidebb-hosszabb időre egy másik felhasználó szerepkörére váltsanak. A Unix rendszerek több paranccsal is segítik ez a feladatot, ezeket tekintjük most át.
8.5.1. A su¶
Az egyes felhasználóknak más-más jogosultságuk van a rendszerben. Egy cég szerverén pl. az ügyintézők nem szabad, hogy hozzáférjenek a vezetők mappáihoz, fájljaihoz, míg fordítva ez valószínűleg nincs így. A bejelentkezési név és jelszó azonosítja a felhasználót, és a rendszer csak annyit enged meg neki, amire a rendszergazda jogosította.
Megjegyzés
Emlékeztető: az elindított program jogosultságai meg fognak egyezni az azt indító felhasználó jogosultsági körével, melyet a setuid és a setgid jogok beállításával lehet megkerülni. Ha szükséges, nézz vissza a Speciális jogok c. részhez.
Egy rosszul beállított jogosultsági rendszer megakadályozhatja a felhasználót abban, hogy a munkáját el tudja végezni. Ennek tesztelésére a rendszergazda számára egy kézzel fogható módszer, hogy az adott felhasználó környezetében próbálja ki, hogy minden rendben van-e. Mivel a felhasználó jelszavát nem ismeri, azt visszafejteni nem tudja, ezért nem tud bejelentkezni a nevében. Hogy a tesztelést el tudja végezni, „át tud váltani egy másik felhasználóra” a su (superuser) parancs segítségével. Használata egyszerű, paraméterként a cél felhasználó bejelentkezési nevét kell megadni (a - megadása esetén a su végrehajtja a már korábban említett .bashrc
, .profile
és egyéb fájlok tartalmát). Az alábbi példában a rendszergazda átvált az én felhasználómra, ebben a helyzetben már csak az én jogkörömmel rendelkezik, amit a # megváltozása is jelez a promptban.
root@columbo:~# su - feri
feri@columbo:~$
A parancs neve onnan ered, hogy root-ként dolgozva a rendszerben bármely fájlhoz hozzáférsz, bármilyen műveletet elvégezhetsz, a jogosultsági rendszer nem korlátoz semmiben (na jó, van egy-két kivétel, de azokról majd idejében). Ez viszont rossz esetben azt eredményezi, hogy egy hibásan kiadott paranccsal akár a teljes működő rendszert is törölheted. Ezért az ajánlás az, hogy ha rendszergazda is vagy, csak egy általános jogú felhasználóként dolgozz, és csak a kritikus parancsok végrehajtásának idejére válts át a root felhasználóra pl. így:
feri@columbo:~$ su root
Jelszó:
root@columbo:/home/feri#
Fontos értened, hogy a su parancs úgy működik, hogy az új felhasználó jogosultságaival egy újabb parancsértelmezőt indít el. Ezért a su befejezése a shellből történő kilépéssel, az exit paranccsal, vagy a Ctrl-d billentyűkkel történik. Ekkor visszalépsz az eredeti, a saját jogosultságaiddal rendelkező shellbe.
feri@columbo:~$ exit
kijelentkezés
root@columbo:~#
Megjegyzés
A su használata azért is jellemző, mert sok rendszerben nem teszik lehetővé a rendszergazda közvetlen bejelentkezését, csak a korlátozott felhasználókét, akik második lépésben váltanak át a rendszergazdai jogkörre. Így egy esetleges támadó számára hiába ismert a rendszergazda neve, felesleges a jelszavakkal próbálkoznia, mert akkor sem tud vele bejelentkezni, ha azt esetleg kitalálná. A korlátozott jogú felhasználó neve pedig már nem nyilvánvaló, ezért azt kideríteni további feladatot jelent számára.
8.5.2. A sudo¶
A su használata nagyon nehézkes, ha csak egy-egy parancs kedvéért kell root hozzáférésre váltani. Mindig meg kell adnod a jelszót, akkor is, ha azt nemrég már begépelted. Egy másik hátrány, hogy ezzel a módszerrel egy teljes jogú parancsértelmezőre váltasz, bármilyen parancsot kiadhatsz, nem lehet csak bizonyos feladatokra korlátozni a rendszergazdai hozzáférést.
Ezekre a helyzetekre a sudo parancs használatos. A sudo esetében a rendszergazda részletesen meghatározhatja, hogy mely parancsokat hajthatod végre rendszergazdai jogkörrel (pl. beállíthatod a rendszerórát, de mondjuk a merevlemez partícionálását már nem végezheted el). Így a rendszergazda „inasai” csak olyan üzemeltetői tevékenységet végezhetnek, amelyekhez jogosultságot kaptak.
A használata egyszerű, a rendszergazdaként végrehajtandó parancs elé a sudo parancsot kell írni. Az első sudo használatkor a rendszer kérni fogja a jelszavadat (tehát a tiédet, nem a root-ét), és innentől egy ideig már nem kell azt a következő sudo használatakor megadnod.
Lássunk egy példát, nézzünk be a rendszergazda home könyvtárába, amely a felhasználók számára nem engedélyezett, így első próbálkozásunkat a rendszer elutasítja:
feri@columbo:~$ ls -l /root
ls: nem lehet a következő könyvtárat megnyitni: /root: Engedély megtagadva
De a sudo parancs használatával láthatom a tartalmát (te nem, mert csak én lettem jogosítva erre):
feri@columbo:~$ sudo ls -l /root
[sudo] password for feri:
összesen 224
-rw-r--r-- 1 root root 35 márc 10 16:58 alma
drwxr-xr-x 2 root root 4096 ápr 11 2016 arch
drwxr-xr-x 2 root root 4096 ápr 27 11:00 awk
8.5.3. A whoami¶
Mivel a felhasználók a su paranccsal identitást válthatnak, ezért a rendszer biztosít egy whoami nevű parancsot, amely visszaadja, hogy épp melyik felhasználóként dolgozunk. Ugyanerre a célra egy másik parancs is jól használható, az id, amely az adott felhasználó csoporttagságait is megmutatja:
feri@columbo:~$ whoami
feri
feri@columbo:~$ id
uid=1158(feri) gid=1158(feri) csoportok=1158(feri),27(sudo),104(fuse),106(whoopsie)
feri@columbo:~$ su - root
Jelszó:
root@columbo:~# whoami
root
root@columbo:~# id
uid=0(root) gid=0(root) csoportok=0(root)
root@columbo:~# exit
kijelentkezés
feri@columbo:~$ whoami
feri
8.6. Ütemezett feladatok¶
A programok indítását ütemezheted is, előírhatod, hogy mely időpontban, vagy időközönként indítsa el azt az operációs rendszer. A Unixokban az egy alkalommal történő indítás teljesen eltér a rendszeres időközönkéntitől, ezeket két különböző háttérrendszer végzi. Ha a programod indítását csak késleltetni akarod, az at parancsra lesz szükséged, a rendszeres indításhoz pedig a crontab-ra.
8.6.1. Az at¶
Az at parancs paraméterként meg kell adnod az indítás idejét, de a futtatandó parancsokat már interaktív módon kell megadnod. A parancsok bevitelét a Ctrl-d zárja. Minden ütemezett feladat (másnéven job) egy azonosító számot, ún. jobid-t kap, a későbbiekben ezzel lehet hivatkozni rá. Az alábbi példában 18:00 órára ütemezzük a ls -l /usr >/tmp/tartalom.txt parancs végrehajtását, amely a 396-os jobid-t kapja:
feri@columbo:~$ at 18:00
warning: commands will be executed using /bin/sh
at> ls -l /usr >/tmp/tartalom.txt
at> <EOT>
job 396 at Sun Nov 25 18:00:00 2018
Az ütemezett feladatok listázhatók az atq paranccsal:
feri@columbo:~$ atq
396 Sun Nov 25 18:00:00 2018 a feri
Amennyiben törölni szeretnél egy ütemezett feladatot, az atrm parancsot kell használnod, paraméterként a törlendő ütemezett feladat azonosítóját kell megadni:
feri@columbo:~$ atrm 396
Az eddigiek alapján bízom benne, hogy nyilvánvaló: egy ütemezett feladat annak a felhasználónak a jogosultságaival fut le, aki azt ütemezte, valamint hogy az ütemezett feladatok megjelenítését és törlését csak a tulajdonosa, illetve a rendszergazda végezheti.
Érdemes megérteni az at működését! Ez nagyon egyszerű, egy job létrehozásakor tulajdonképp csak egy szövegfájlt készít, amelyet a rendszer egy meghatározott helyére, a columbo.uni-eszterhazy.hu esetében a /var/spool/cron/atjobs/
könyvtárba tesz. Ezeket a fájlokat egy háttérprogram, az atd percenként ellenőrzi, és ha valamelyiket az adott percre ütemezték, végrehajtja azt az ütemezett feladat tulajdonosának jogkörével. Ezek után könnyű elképzelni az atd és az atrm működését is, a lényegük ezek fájlok kiolvasása, illetve törlése.
root@columbo:~# ls -l /var/spool/cron/atjobs/
összesen 4
-rwx------ 1 root daemon 2235 nov 25 21:03 a0018d018876b4
8.6.2. A cron¶
Az at nem alkalmas arra, hogy rendszeresen ismétlődő feladatokat hajtsunk végre vele, csak egy időpontra ütemezhető a program indítása. Ezért a Unixok egy másik alrendszert is tartalmaznak, a cront.
Egy feladat ütemezése a cron esetében már bonyolultabb, mert összetett ismétlődési időpontokat is le kell tudnunk írni számára. Egy feladat meghatározására a crontab -e parancs szolgál, amely megnyitja azt a szövegfájlt, amely az adott felhasználó ismétlődő feladatait tartalmazza. Ez a fájl kezdetben csak kettőskereszttel kezdődő, csak megjegyzéseket tartalmazó sorokat tartalmaz, melyek leírják a feladat ütemezésének szabályait. Az egyes feladatokat célszerűen a fájl végére, egy-egy önálló sorba kell leírnod.
feri@columbo:~$ crontab -e
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
A feladatokat leíró sorok mindegyikének követnie kell a cron által elvárt szintaxist. Ez két részből áll, az első blokk a végrehajtás időpontjait határozza meg, ez után pedig a végrehajtandó programot kell meghatározni. Az időpontok leírásához a fájl utolsó sora ad segítséget, érdemes ezt követni. Öt számot kell meghatározni, melyek bármelyike helyett írható * karakter is. Lássuk ezeket sorban!
Az első helyen a végrehajtás perceit kell meghatározni. A 32 azt jelenti, hogy a 32. percben, a 32,45 (szóközök nélkül) azt, hogy a 32. és a 45. percben is. A 12-15 jelentése: a 12. és a 15. perc közt minden percben. A * azt jelenti, hogy a végrehajtást minden percben meg kell tenni. Speciális megadási módja van az n percenkénti megadásnak: a */2 minden második, a */12 minden 12. percbeni futtatást eredményez.
A második pozíción az órákat kell meghatározni. A szabály ugyanaz, mint a perceknél: megadható egy 0-23 intervallumba eső érték, vesszővel elválasztva felsorolhatók órák, kötőjellel elválasztva intervallum határozható meg. A * jelentése minden órában; a */szám is a már ismertetett jelentéssel bír.
A harmadik pozíción a napokat lehet meghatározni.
A negyediken a hónapokat.
Az ötödiken nem az éveket (azok ugye nem ismétlődnek), hanem a nap sorszámát lehet megadni, ezzel tudod meghatározni pl. azt, hogy a program csak péntekenként induljon el. A számozás 1-től 7-ig tart, az 1 értelemszerűen a hétfőt, a 7 a vasárnapot jelenti.
Lássuk, hogyan lehetne az at-nál már kipróbált ls -l /usr >/tmp/tartalom.txt parancsot minden páros hónap 1-jén, ha az péntek, de csak minden negyedik órában, a 30., 45. és a 47. percében!
feri@columbo:~$ crontab -e
#
30,45,47 */4 1 */2 5 ls -l /usr >/tmp/tartalom.txt
Az ütemezett feladatok definiálására további fájlok is vannak a rendszerben. A /etc/crontab
fájlban a rendszergazda adhatja meg az ütemezett feladatok leírását, ebben az esetben az időpontok meghatározását a futtatást végző felhasználó nevének kell követnie. Személy szerint nem ajánlom ennek használatát, helyette inkább az alább ismertetett /etc/cron.d
könyvtárét.
A /etc/cron.d
könyvtárban az egyes rendszerekhez tartozó ütemezett feladatok fájljai találhatók. A rendszergazdának a gyakorlatban sokkal könnyebb dolga van, ha feladatokat szeparált fájlokban írhatja le, mert az egyes szoftverek telepítésekor és törlésekor csak egy-egy fájl bemásolására, illetve törlésére van szükség (ezek tartalmazzák a hozzájuk tartozó ütemezett feladatok definícióit). Nem mellesleg ezzel a módszerrel elkerülhető az a tipikus hiba is, hogy egy szintaktikai hiba következtében a teljes /etc/crontab
tartalmát figyelmen kívül hagyja a rendszer, aminek következménye lehet a mentési feladatok, vagy más fontos programok futásának elmaradása.
További könyvtárak is vannak a rendszerben, amelyek ugyanezt a célt szolgálják:
feri@columbo:~$ ls -ld /etc/cron.*
drwxr-xr-x 2 root root 4096 szept 24 11:05 /etc/cron.d
drwxr-xr-x 2 root root 4096 jún 5 15:11 /etc/cron.daily
drwxr-xr-x 2 root root 4096 ápr 29 2014 /etc/cron.hourly
drwxr-xr-x 2 root root 4096 ápr 29 2014 /etc/cron.monthly
drwxr-xr-x 2 root root 4096 ápr 10 2017 /etc/cron.weekly
A könyvtárak nevei beszédesek: a cron.daily
fájljai naponta, a cron.hourly
-ban levő óránként futnak le. (A másik kettőt szerintem már kitaláltad.) Ezek működése egyébként rendkívül egyszerű, ha látni szeretnéd, miért indulnak el ezek, nézd meg a /etc/crontab
fájl első néhány sorát.
Az crontab működési mechanizmusa szinte megegyezik az at parancsnál már megismertére. Ebben az esetben is fájlok keletkeznek, a /var/spool/cron/crontabs/
könyvtárba tesz. Ezeket is egy háttérprogram, a cron ellenőrzi, és az adott percre ütemezetteket, végrehajtja.
root@columbo:~# ls -l /var/spool/cron/crontabs/
összesen 44
-rw------- 1 feri crontab 1161 márc 17 2017 feri
8.7. Processzkezelés¶
A programok futtatásához azokat az operatív memóriába kell tölteni majd el kell indítani. A memóriában levő, futó példány neve processz vagy más néven folyamat. Minden operációs rendszer alapvető feladata ezek menedzselése, és a legtöbbjük különféle eszközöket (parancsokat vagy programokat) biztosít a kezelésükre. A Unix rendszerek számos, a processzek kezelésre szolgáló parancsot tartalmaznak, ezeket tekintjük most át.
Egy processz az életciklusa az alábbi állapotok valamelyikében lehet:
Az első, az ún. létrehozás alatt állapotba a processz közvetlenül a program memóriába töltése után kerül. Ebben az állapotban még nincs futtatható állapotban, hanem az ehhez szükséges előzetes feladatok végrehajtása történik meg.
A futáskész állapotú processz nem fut, de alkalmas arra, hogy az operációs rendszer ütemezője elkezdje azt végrehajtani.
Futó állapotban akkor van egy processz, amikor azt a kernel elkezdi végrehajtani. Ebbe az állapotba csak a futáskész állapotból kerülhet.
Alvó állapotú egy processz, ha pl. valamilyen inputra vagy perifériára vár. Ebben az esetben nem lenne szerencsés, ha futáskész állapotban maradna, hiszen hiába kerülne rá a vezérlés, azt úgyis csak semmittevéssel (várakozással) töltené. Ebben az állapotban nem kerül rá a vezérlés, és akkor kerül futáskészbe, ha az alvó állapotot kiváltó adat megérkezik.
Előbb-utóbb minden processzt le kell állítani, ennek folyamata során terminált állapotba kerül. Ez a megszűnés előtti utolsó állapot, ebben már csak a szabályos kilépést szolgáló kódrészletek futnak le.
8.7.1. A PCB¶
Az egyes processzeket nyilván kell tartani, erre minden operációs rendszer egy struktúrát tart fenn. Egy tipikus megoldás lehet erre egy láncolt lista, amelynek elemei egy-egy processzt leíró adatstruktúrát, a process control block-ot, röviden PCB-t tartalmaznak. A lista egy gépi szinten könnyen megvalósítható szerkezet, amelybe könnyű újabb elemet felvenni, vagy bármelyiket törölni.
Lássunk néhány jellemző PCB elemet!
- sorszám:
A processz azonosító száma, erre a processz kezelése során lesz majd szükség, ezzel azonosítható egy processz. A sorszámot gyakran nevezik processz ID-nek, röviden PID-nek is.
- processz állapot:
Értelemszerűen a processz aktuális állapotát írja le (futó, futáskész, alvó stb.).
- program counter:
Mivel a processzek végrehajtása rövid időszeletekben történik, nyilván kell tartani, hogy az éppen hol tart, erre szolgál ez az elem. Amikor a processz futó állapotba kerül, ezt kiolvasva lehet meghatározni, hogy honnan kell annak futását folytatni.
- CPU regiszterek:
A processzor regisztereinek állapotát tárolja, hasonlóan az előzőhöz, innen kell visszatölteni a korábbi állapotot, amikor a processz állapota újra futó lesz.
- Nyitott fájlok:
Az egyes fájlok megnyitását a rendszernek nyilván kell tartani pl. azért, hogy megvalósítható legyen az a zárolási mechanizmus, amely megakadályozza, hogy egy fájt több processz is írni próbáljon. Ez az elem ezek tárolására szolgál. Ezen alapul a lsof (LiSt Open Files) parancs is, amely felsorolja a rendszer nyitott fájljait és megjeleníti az őket megnyitó processzek nevét és PID-jét.
- futási idők:
A time parancs egy program futásának idejét méri, ez a PCB leíró részeit használja fel ahhoz, hogy a teljes futásidő mellett meg tudja adni, hogy valójában mekkora időszeletet töltött a rendszer az adott processz futtatásával. Utóbbi idő a gyakorlatban értelemszerűen kevesebb lesz, mint a teljes mért idő, hiszen a vezérlés más processzekre, illetve a rendszert működtető kernelre is átkerült.
8.7.2. Processzkezelő parancsok¶
Az egyes processzek állapotának monitorozására több parancsot is kínál a rendszer, az általánosan használt a ps. Ez felsorolja az összes futó processzt, és mindegyikükről megjelenít néhány információt. Az alábbi ábrán a ps kimenetének egy részlete látható (mivel a teljes lista általában nem fér el a képernyőn, érdemes a less szűrővel oldalakra bontva vizsgálódni):
feri@columbo:~$ ps axu | less
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 33488 1888 ? Ss aug19 0:35 /sbin/init
root 2 0.0 0.0 0 0 ? S aug19 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S aug19 0:11 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< aug19 0:00 [kworker/0:0H]
root 7 0.0 0.0 0 0 ? S aug19 2:01 [rcu_sched]
Az első sorban levő fejléc írja le az egyes oszlopok jelentését. Ezek közül szeretnék kiemelni néhányat, ami a gyakorlati munka során fontos lehet:
- USER:
A processz tulajdonosa. Ő indította el az adott processzt, vagy háttérben futó szolgáltatást. Azért is fontos ismerni, mert a processz az ő jogosultsági körével rendelkezik.
- %PID:
A Process ID, azaz a processz azonosítója. A processzek kezelése során fogjuk használni.
- %CPU:
Az adott processz processzor felhasználásának mértékét fejezi ki %-ban. Ez az üzemeltető számára azért fontos, mert ennek ismeretében megállapítható, mely processzek terhelik okozzák a rendszer terhelését.
- %MEM:
Ez az érték a felhasznált rendszermemória mennyiségére utal, minél nagyobb, annál több memóriát használ fel a processz. Ez is a rendszer terhelésének vizsgálatakor jelent hasznos adatot.
- STAT:
A processz állapota. Ez többféle lehet, a legtöbbet az alvó állapotú processzekből találsz majd, ezek azok, amelyek valamilyen inputra várnak, és annak megérkezéséig a kernel nem futtatja (hanem altatja) őket. Az alvó processzeket az S (sleeping), a futókat az R (running) karakterekkel jelölik. A további processz állapotokról részletes listát és magyarázatot kaphatsz a ps kézikönyvében.
- START, TIME:
A processz indításának dátuma és ideje.
- COMMAND:
Az elindított program vagy szolgáltatás neve a paraméterekkel együtt. (Emlékszel arra, hogy a jelszó megváltoztatására szolgáló parancs, a passwd mindig interaktív módon kérte be a jelszót, nem adhattad meg az új jelszót paraméterként? Ha ezt a passwd lehetővé tenné, egy alkalmas pillanatban kiadott ps parancs kimenetében olvasható lenne az épp beállított új jelszó.)
Már korábban említettem, hogy a rendszer boot folyamata során a kernel indulása után az /sbin/init
programot indítja el, és ez végzi a rendszer további részeinek betöltését. (A pontosság kedvéért: a kernelnek egy listája van erre, amelyből az első olyat indítja el, ami az aktuális rendszerben létezik, ez a mi rendszerünkben az init lesz.) Az init végzi a rendszer további elemeinek elindítását, ezért ez lesz minden processz „ősöreganyja”, minden processz ebből származik. Ezért az init leállítása minden processz, így a teljes rendszer leállását eredményezi.
A top egy interaktív program, amellyel monitorozható a rendszer, terheltsége, processzei. A fejlécében leolvasható, hogy a rendszer mióta működik (98 napja), mekkora a terhelése (0,00, 0,01, 0,05), a processzek száma, állapota és a memória használat mértéke. A második blokkban a ps parancshoz hasonlóan az egyes processzek adatai láthatók. A top alapértelmezésben kétmásodpercenként újraírja a képernyőt az aktuális értékekkel, valamint utasításokat is fogad a felhasználótól. Ezek közt a megjelenés beállításai mellett sok más, pl. az egyes processzek terminálása is szerepel.
top - 22:24:30 up 98 days, 10:10, 3 users, load average: 0,00, 0,01, 0,05
Tasks: 111 total, 2 running, 106 sleeping, 3 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,0 sy, 0,0 ni,100,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 1017772 total, 792428 used, 225344 free, 69668 buffers
KiB Swap: 499708 total, 67888 used, 431820 free. 472660 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1183 root 20 0 0 0 0 S 0,3 0,0 75:12.61 kworker/0:2
1 root 20 0 33488 1728 644 S 0,0 0,2 0:39.96 init
2 root 20 0 0 0 0 S 0,0 0,0 0:00.17 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:13.29 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0,0 0,0 2:13.97 rcu_sched
8 root 20 0 0 0 0 R 0,0 0,0 4:01.66 rcuos/0
9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcuob/0
11 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/0
12 root rt 0 0 0 0 S 0,0 0,0 0:31.23 watchdog/0
Megjegyzés
A top több alternatívája is telepíthető egyes Unix rendszerekbe. Ezért találkozhatsz más, hasonló nevűekkel is, egy elterjedt példája a htop, amely az egyes processzor magok terhelését is képes megjeleníteni.
A rendszer működési idejét és a pillanatnyi terhelését a top mellett a w parancs is megjelenítette (lásd a A bejelentkezett felhasználók parancsról szóló részt). Ha kifejezetten erre az információra van szükség, akkor az uptime parancsot érdemes elővenni:
root@columbo:~# uptime 22:37:47 up 98 days, 10:24, 3 users, load average: 0,00, 0,01, 0,05
A processzek listáját a pstree paranccsal is meg lehet jeleníteni, ennek kimenete a processzek egymáshoz való viszonyát írja le. Az alábbi ábrán látható, hogy a processzek fastruktúrába rendezettek, melynek gyökerében az init áll. A fában szerepelnek sshd-k, ezek fogadják a távoli bejelentkezéseket, ezzel épít ki kapcsolatot pl. a Putty is. Látható a fában a nemrég említett atd és a cron is, ők hajtáják végre az ütemezett feladatokat. A szemfüles olvasó felfedezheti a listában magát a pstree parancsot is, amely épp a fát rajzolta ki a képernyőre.
root@columbo:~# pstree
init─┬─ManagementAgent───2*[{ManagementAgent}]
├─VGAuthService
├─acpid
├─atd
├─cron───cron───sh───check_sys_EVERY───sleep
├─dbus-daemon
├─exim4
├─6*[getty]
├─inetd
├─ls
├─mysqld───17*[{mysqld}]
├─rsyslogd───3*[{rsyslogd}]
├─3*[screen───bash]
├─screen───bash───screen───screen───bash
├─screen───2*[bash]
├─screen─┬─bash───screen───screen───bash
│ └─bash
├─sshd───sshd───sshd───bash─┬─bash───sudo───bash───pstree
│ └─l1───sleep
├─systemd-logind
├─systemd-udevd
├─upstart-file-br
├─upstart-socket-
├─upstart-udev-br
└─whoopsie───2*[{whoopsie}]
8.8. A szignálok¶
Az operációs rendszerek jó része biztosít valamilyen funkciót arra, hogy az egyes processzek egymással kommunikálni tudjanak. A Unix rendszerek esetében az egyik ilyen lehetőség a szignálok alkalmazása. A szignálok tulajdonképpen üzenetek, amelyeket az a processz, amely számára azt küldték, képes fogadni. Az üzenetek feldolgozása egy erre a célra definiált függvényben (signal handlerben) történik meg, értelemszerűen csak abban az esetben, ha a program készítője definiálta azt. Tulajdonképpen már két üzenet típust ismersz is: a Ctrl-c és a Ctrl-d is így kommunikál. A Ctrl-c egy ún. INT szignált, a Ctrl-z pedig egy STOP szignált küld az adott terminálban futó processznek, ha az tartalmaz az adott szignál vételéhez tartozó függvényt, végre fogja azt hajtani. (így lehetséges, hogy egyes programok futását nem tudod megszakítani a Ctrl-c-vel.) Nem minden szignálhoz kell, hogy tartozzon handler függvény, ezek elkészítése és implementálása a program megtervezésekor dől el.
Elég sokféle szignál típus létezik, számukat az egyes szabványok változásai során többször bővítették is. Az alábbi ábra néhányat sorol fel ezek közül (ezt a man 7 signal paranccsal megjelenített kézikönyvből ollóztam össze).
Signal Value Action Comment
──────────────────────────────────────────────────────────────────────
SIGHUP 1 Term Hangup detected on controlling terminal
or death of controlling process
SIGINT 2 Term Interrupt from keyboard
SIGKILL 9 Term Kill signal
SIGTERM 15 Term Termination signal
A szignálokat leggyakrabban két okból használjuk, az egyik a processzek terminálása (futásának megszakítása), a másik pedig a konfigurációs fájl újraolvasására. Lássuk a szignálok küldésének parancsait!
Szignál küldésére a kill parancs szolgál. Feladata a nevével ellentétben nem feltétlenül a terminálás, valószínűleg történeti oka lehet annak, hogy így hívják. A legtöbb esetben két paraméterrel használjuk, a küldendő szignál nevével és annak a processznek az id-jével, amelynek a szignált küldeni szeretnénk. Amennyiben a szignál nevét nem adod meg, az alapértelmezett 15-ös számú ún. SIGTERM szignált küldi, amely arra utasítja a processzt, hogy lépjen ki. Az alábbi parancs a 30990-es id-jű processz számára küld egy terminálási utasítást:
root@columbo:~# kill 30990
Fontos, hogy értsd: a szignál vételekor a processz SIGTERM-hez rendelt függvénye fut le, ha van ilyen. Ebben szokás törölni a program által létrehozott ideiglenes fájlokat, lezárni a nyitott fájl-, vagy hálózati kapcsolatokat stb. Adott megvalósításban a processz ebben a függvényben úgy is dönthet, hogy nem lép ki.
A következő példában SIGINT szignált küldünk a 3126-os processz id-jű processznek, a szignál nevét egy - karakternek kell megelőznie:
root@columbo:~# kill -SIGINT 3126
A szignál neve helyett annak száma is használható, ez a SIGINT esetében 2:
root@columbo:~# kill -2 3126
Megjegyzés
Nem mindegyik szignálról értesül a címzett processz. A SIGKILL küldésekor az üzenetet már csak az operációs rendszer fogadja, és kérdés nélkül terminálja a processzt. Ez sokkal durvább megoldás, és csak abban az esetben érdemes használni, ha az alapértelmezett SIGTERM-re nem szakad meg a program futása.
A killall két paramétere a küldendő szignál neve és egy program neve, hatására az adott nevű program összes példány megkapja a megadott szignált. Ebben az esetben is az alapértelmezés a SIGTERM szignál lesz. Az alábbi példában az összes futó Midnight Commander számára SIGTERM szignált küldünk, melynek hatására mindegyik példány azonnal befejezi a futását:
root@columbo:~# killall mc
A felhasználó értesül arról, hogy a programját terminálták, a befejeződött felirat megjelenése egyértelműen erre utal.
│ │ │ ││ │ │ │
├───────────────────────────────────────────────────────────────┤├──────────────────────
│SZ-KVTR ││SZ-KVTR │
└─────────────────────────────────────────────── 11G/11G (98%) ─┘└──────────────────────
Tipp: Az FTP be van építve a Midnight Commanderbe: "FTP-kapcsolat" menüpontok.
root@columbo:~/bin# Befejeződött
Ha a küldött szignál a -9, azaz a processzt annak értesítése nélkül termináljuk, a kilőve szöveg jelenik meg:
root@columbo:~# killall -9 mc
│ │ │ ││ │ │ │
├───────────────────────────────────────────────────────────────┤├──────────────────────
│SZ-KVTR ││SZ-KVTR │
└─────────────────────────────────────────────── 11G/11G (98%) ─┘└──────────────────────
Tipp: Az FTP be van építve a Midnight Commanderbe: "FTP-kapcsolat" menüpontok.
root@columbo:~/bin# Kilőve
Megjegyzés
A killall egy alternatívájaként találkozhatsz a pkill paranccsal, hatásuk nagyjából megegyezik: mindkettő a megadott nevű processzeknek küld szignált.
A slay paraméterei a szignál neve és egy felhasználó, a parancs a megadott szignált küldi ki a meghatározott felhasználó összes processzének. A példában a Z8JDN8 felhasználó minden processzének SIGTERM szignált küldök:
root@columbo:~# slay Z8JDN8
slay: Done.
Megjegyzés
A slay nagyon jól jön akkor, ha a rendszergazda észreveszi, hogy valamelyik felhasználó hozzáférérést feltörték és a rendszerben nemkívánatos programokat futtatnak vele. A paranccsal minden, általa indított program azonnal leállítható.
A pgrep a futó processzek közül megjeleníti azok id-jét, amelyek neve tartalmazza a paraméterként megadott stringet. Az sshd-k processz id-it az alábbi parancs írja a képernyőre:
root@columbo:~# pgrep sshd
21244
28262
28378
A fenti parancsok további paraméterekkel is rendelkeznek, érdemes egy kis időt rászánni a paramétereik átolvasására.
8.9. Ellenőrző kérdések¶
Hogyan indítható egy program Unix rendszerekben?
Milyen jogosultsággal kell rendelkeznie egy programnak ahhoz hogy futtatható legyen? Hogy lehet ezt beállítani?
Mi a PATH környezeti változó feladata? Hoygan kerül alapértelmezésben beállításra ez?
Hogyan kezelhető a processzek prioritása?
Mik az álnevek és hogyan kezelhetők?
Hogyan futtathatók a programok háttérben?
Mi a screen?
Hogyan lehet más felhasználók identitásával programokat futtatni?
Hogyan lehet ütemezett feladatokat létrehozni és kezelni?
Hogyan lehet rendszeresen végrehajtandó feladatokat létrehozni és kezelni?
Hogyan működik az operációs rendszerek processzkezelése? Mi a PCB?
Milyen processzkezelő parancsokat ismer?
Mik a szignálok? Milyen parancsok kapcsolódnak hozzájuk?
8.10. Feladatok¶
Milyen processzek futnak a rendszerben?
Jelenítsd meg a futó processzek listáját fa elrendezésben!
Milyen processzek futnak most a rendszerben, amelynek a tulajdonosa a root?
Mi a processz id-je az init nevű processznek? Miért?
Jelentkezz be még egy példányban és indítsd el az mc nevű programot!
A másik Putty ablakban kérdezd le ennek a Commandernek a process id-jét, majd küldj neki egy TERM szignált!
Egyetlen paranccsal termináld az összes processzedet!
Jelenítsd meg a futó processzek listáját terhelés szerint! Monitorozd folyamatosan a terhelést!
Keresd meg a rendszer összes .conf kiterjesztésű fájlját és azok listáját írd a
/tmp/find-<username>.txt
fájlba! Mivel ez sokáig fut, a keresést a háttérben végezd!Végezd el az előző feladatot úgy, hogy a hibaüzenetek ne kerüljenek a képernyőre!
Végezd el újra az előző feladatot úgy, hogy az alacsony prioritással fusson!
Az előző feladat fusson le minden éjjel 3:10-kor! (A háttérben futtatás & jelére ebben az esetben nincs szükség. Ne felejtsd el törölni ezt a beállítást, amikor végzett a feladattal!)
Éjfélkor írd ki a
/tmp/free-<username>.txt
fájlba a szabad hely nagyságát!Jelenítsd meg az ütemezett feldataid listáját!
10 órakor készíts másolatot a
/etc/passwd
fájlról a /tmp könyvtárba!Töröld ezt az időzített feladatot!