We zullen dit artikel beginnen met een algehele en beknopte herziening van wat er gebeurt vanaf het moment dat je op de Power-knop drukt om je RHEL 7-server in te schakelen totdat je wordt gepresenteerd met het aanmeldscherm in een opdrachtregelinterface.
Houd er rekening mee dat:
1. dezelfde basisprincipes gelden, met mogelijk kleine aanpassingen, voor andere Linux-distributies, en
2. de volgende beschrijving is niet bedoeld als een uitputtende uitleg van het opstartproces, maar alleen van de fundamentele aspecten.
Linux Opstartproces
1. De POST (Power On Self Test) initialiseert en voert hardwarecontroles uit.
2. Wanneer de POST is voltooid, wordt de systeemcontrole doorgegeven aan de eerste fase van de opstartlader, die is opgeslagen op de opstartsector van een van de harde schijven (voor oudere systemen die BIOS en MBR gebruiken) of een speciale (U)EFI-partitie.
3. De eerste fase van de opstartlader laadt vervolgens de tweede fase van de opstartlader, meestal GRUB (GRand Unified Boot Loader), die zich bevindt binnen /boot, die op zijn beurt de kernel en het initiële RAM-gebaseerde bestandssysteem laadt (ook bekend als initramfs, dat programma’s en binaire bestanden bevat die de noodzakelijke acties uitvoeren om uiteindelijk het daadwerkelijke root-bestandssysteem te monteren).
4. We worden gepresenteerd met een splash-scherm dat ons in staat stelt om een besturingssysteem en kernel te kiezen om op te starten:
5. De kernel configureert de hardware die aan het systeem is gekoppeld en zodra het hoofdbestandssysteem is gemount, start het proces met PID 1, dat op zijn beurt andere processen zal initialiseren en ons een aanmeldingsprompt zal tonen.
Opmerking: Als we dit op een later tijdstip willen doen, kunnen we de details van dit proces bekijken met behulp van het dmesg commando en de uitvoer filteren met behulp van de gereedschappen die we hebben uitgelegd in eerdere artikelen van deze serie.
In het bovenstaande voorbeeld hebben we het bekende ps commando gebruikt om een lijst weer te geven van huidige processen waarvan het ouderproces (of met andere woorden, het proces dat ze heeft gestart) systemd is (de systeem- en servicedirecteur waar de meeste moderne Linux-distributies naar zijn overgeschakeld) tijdens het opstarten van het systeem:
# ps -o ppid,pid,uname,comm --ppid=1
Onthoud dat de -o-vlag (kort voor –format) u in staat stelt de uitvoer van ps in een aangepast formaat weer te geven om aan uw behoeften te voldoen met behulp van de trefwoorden die zijn gespecificeerd in de STANDAARD FORMAAT SPECIFICATORS-sectie in man ps.
Nog een geval waarin u de uitvoer van ps wilt definiëren in plaats van de standaard te volgen, is wanneer u processen moet vinden die een aanzienlijke CPU- en/of geheugenbelasting veroorzaken, en deze dienovereenkomstig moet sorteren:
# ps aux --sort=+pcpu # Sort by %CPU (ascending) # ps aux --sort=-pcpu # Sort by %CPU (descending) # ps aux --sort=+pmem # Sort by %MEM (ascending) # ps aux --sort=-pmem # Sort by %MEM (descending) # ps aux --sort=+pcpu,-pmem # Combine sort by %CPU (ascending) and %MEM (descending)
Een inleiding tot SystemD
Weinig beslissingen in de Linux-wereld hebben meer controverses veroorzaakt dan de adoptie van systemd door belangrijke Linux-distributies. De voorstanders van systemd noemen als belangrijkste voordelen de volgende feiten:
Lees ook: Het Verhaal Achter ‘init’ en ‘systemd’
1. Systemd maakt meer parallelle verwerking mogelijk tijdens het opstarten van het systeem (in tegenstelling tot oudere SysVinit, die altijd langzamer lijkt te zijn omdat het processen één voor één start, controleert of de ene afhankelijk is van de andere, en vervolgens wacht tot daemons zijn gestart zodat meer services kunnen starten), en
2. Het werkt als dynamisch bronnenbeheer in een draaiend systeem. Daarom worden services gestart wanneer dat nodig is (om te voorkomen dat systeembronnen worden verbruikt als ze niet worden gebruikt) in plaats van zonder geldige reden tijdens het opstarten te worden gestart.
3. Achterwaartse compatibiliteit met SysVinit-scripts.
Systemd wordt gecontroleerd door het hulpprogramma systemctl. Als je uit een SysVinit-achtergrond komt, is de kans groot dat je bekend bent met:
- het service-gereedschap, dat -in die oudere systemen- werd gebruikt om SysVinit-scripts te beheren, en
- het chkconfig-hulpprogramma, dat diende om runlevel-informatie voor systeemservices bij te werken en te bevragen.
- afsluiten, die je waarschijnlijk al meerdere keren hebt gebruikt om een systeem opnieuw op te starten of af te sluiten.
De volgende tabel toont de overeenkomsten tussen het gebruik van deze verouderde tools en systemctl:
| Legacy tool | Systemctl equivalent | Description |
| service name start | systemctl start name | Start name (where name is a service) |
| service name stop | systemctl stop name | Stop name |
| service name condrestart | systemctl try-restart name | Restarts name (if it’s already running) |
| service name restart | systemctl restart name | Restarts name |
| service name reload | systemctl reload name | Reloads the configuration for name |
| service name status | systemctl status name | Displays the current status of name |
| service –status-all | systemctl | Displays the status of all current services |
| chkconfig name on | systemctl enable name | Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory. |
| chkconfig name off | systemctl disable name | Disables name to run on startup as specified in the unit file (the file to which the symlink points) |
| chkconfig –list name | systemctl is-enabled name | Verify whether name (a specific service) is currently enabled |
| chkconfig –list | systemctl –type=service | Displays all services and tells whether they are enabled or disabled |
| shutdown -h now | systemctl poweroff | Power-off the machine (halt) |
| shutdown -r now | systemctl reboot | Reboot the system |
Systemd introduceerde ook de concepten van units (die ofwel een service, een mount point, een apparaat of een netwerksocket kunnen zijn) en targets (dit is hoe systemd erin slaagt om verschillende gerelateerde processen tegelijk te starten, en kan worden beschouwd – hoewel niet gelijk – als het equivalent van runlevels in SysVinit-gebaseerde systemen.
Samenvattend
Andere taken met betrekking tot procesbeheer omvatten, maar zijn mogelijk niet beperkt tot, de mogelijkheid om:
1. De uitvoeringsprioriteit aanpassen wat betreft het gebruik van systeembronnen van een proces:
Dit wordt bereikt met behulp van het renice hulpprogramma, dat de planningsprioriteit van één of meer lopende processen wijzigt. In eenvoudige bewoordingen is de planningsprioriteit een functie die de kernel (aanwezig in versies => 2.6) in staat stelt systeembronnen toe te wijzen volgens de toegewezen uitvoeringsprioriteit (ook wel niceness genoemd, in een bereik van -20 tot 19) van een bepaald proces.
De basisopmaak van renice is als volgt:
# renice [-n] priority [-gpu] identifier
In de bovenstaande generieke opdracht is het eerste argument de prioriteitswaarde die moet worden gebruikt, terwijl het andere argument kan worden geïnterpreteerd als proces-IDs (wat de standaardinstelling is), procesgroeps-IDs, gebruikers-IDs of gebruikersnamen. Een normale gebruiker (anders dan root) kan alleen de planningsprioriteit van een proces aanpassen dat hij of zij bezit en alleen het aantal aardigheid verhogen (wat betekent minder systeembronnen gebruiken).
2. Kill (of onderbreken van de normale uitvoering) van een proces indien nodig:
In meer precieze termen betekent het doden van een proces het sturen van een signaal om het te laten uitvoeren gracieus (SIGTERM=15) of onmiddellijk (SIGKILL=9) via de kill of pkill opdrachten.
Het verschil tussen deze twee tools is dat de eerste wordt gebruikt om een specifiek proces of een procesgroep helemaal te beëindigen, terwijl de laatste dit laat doen op basis van naam en andere kenmerken.
Bovendien wordt pkill geleverd met pgrep, die u de PID’s laat zien die zullen worden beïnvloed als pkill wordt gebruikt. Bijvoorbeeld, voordat u uitvoert:
# pkill -u gacanepa
Het kan nuttig zijn om meteen te zien welke PIDs toebehoren aan gacanepa:
# pgrep -l -u gacanepa
Standaard sturen zowel kill als pkill het SIGTERM signaal naar het proces. Zoals hierboven vermeld, kan dit signaal genegeerd worden (terwijl het proces zijn uitvoering voltooit of voorgoed), dus wanneer je echt een lopend proces met een geldige reden moet stoppen, moet je het SIGKILL signaal specificeren op de commandoregel:
# kill -9 identifier # Kill a process or a process group # kill -s SIGNAL identifier # Idem # pkill -s SIGNAL identifier # Kill a process by name or other attributes
Conclusie
In dit artikel hebben we de basis van het opstartproces in een RHEL 7 systeem uitgelegd, en hebben we enkele van de tools geanalyseerd die beschikbaar zijn om je te helpen bij het beheren van processen met behulp van algemene hulpprogramma’s en systemd-specifieke commando’s.
Merk op dat deze lijst niet bedoeld is om alle ins en outs van dit onderwerp te behandelen, dus voel je vrij om je eigen voorkeurstools en commando’s aan dit artikel toe te voegen via het reactieformulier hieronder. Vragen en andere opmerkingen zijn ook welkom
Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/