Če free -m na strežniku AlmaLinux prikaže manj pomnilnika, kot ga je v paketu VPS, je eden od vzrokov lahko kdump. Kdump ob sesutju jedra shrani vsebino pomnilnika, da je mogoče pozneje ugotoviti vzrok napake. Za to ob zagonu sistema rezervira območje pomnilnika (crashkernel) za drugo, tako imenovano reševalno jedro; tega območja sistem ne uporablja za nič drugega.

Na majhnem VPS je to opazno: na računalniku z 2 GB je privzeta rezervacija 256 MB, osmina pomnilnika. Na večini strežnikov, ki strežejo spletne strani, shranjenih posnetkov kdump nikoli nihče ne analizira, zato je ta pomnilnik bolje uporabiti za aplikacije.

Korake smo oktobra 2026 preizkusili v sistemih AlmaLinux 9.8 in 10.2, na navideznem računalniku z 2 GB pomnilnika.

Ali je na strežniku rezervacija?

grep -o 'crashkernel=[^ ]*' /proc/cmdline
echo $(( $(cat /sys/kernel/kexec_crash_size) / 1048576 )) MB
systemctl is-enabled kdump

• Če prvi ukaz ne izpiše ničesar, drugi pa 0 MB, rezervacije ni in ni kaj storiti. V preizkusu je bilo tako na računalnikih, nameščenih s cloud image AlmaLinux 9 in 10: kdump je bil izklopljen, parametra crashkernel ni bilo. V sistemih, nameščenih z namestitvenim programom (z ISO), pa je privzeto vklopljen.
• Dejansko rezervacijo pokaže tudi zagonski dnevnik jedra: sudo dmesg | grep -i crashkernel, na primer crashkernel reserved: 0x00000000a5400000 - 0x00000000b5400000 (256 MB).

Privzeta vrednost je odvisna od velikosti pomnilnika. Tovarniško nastavitev izpiše sudo kdumpctl get-default-crashkernel; v preizkusu je bila v AlmaLinux 9 aarch64 1G-4G:256M,4G-64G:320M,64G-:576M, torej pri 1–4 GB pomnilnika 256 MB. V sistemu x86_64 so vrednosti manjše (po dokumentaciji Red Hat pri 1–4 GB 192 MB).

1. možnost: manjša rezervacija, kdump ostane

Če želiš kdump obdržati, a mu nameniti manj pomnilnika:

sudo grubby --update-kernel=ALL --args="crashkernel=1G-4G:128M,4G-64G:192M,64G-:256M"
sudo reboot

V preizkusu se je na računalniku z 2 GB rezervacija s tem zmanjšala z 256 MB na 128 MB, skupni pomnilnik po free -m se je povečal s 1699 MB na 1827 MB, storitev kdump pa je bila še vedno active. Pri premajhni rezervaciji se kdump ne more zagnati (systemctl status kdump pokaže napako); takrat vrednost povečaj.

Na tovarniško vrednost jo vrne sudo kdumpctl reset-crashkernel --kernel=ALL (velja po ponovnem zagonu).

2. možnost: izklop kdump

Če kdumpa ne potrebuješ, ga izklopi in odstrani rezervacijo:

sudo systemctl disable --now kdump
sudo grubby --update-kernel=ALL --remove-args="crashkernel"
sudo reboot

V preizkusu je bila nato rezervacija 0 MB, skupni pomnilnik po free -m pa 1955 MB, torej za 256 MB več kot pri rezervaciji 256 MB.

Dve opombi k pogosto citiranim starejšim opisom:

• crashkernel=no ni veljavna vrednost. V preizkusu je rezervacijo sicer odstranil, a le zato, ker ga jedro ni razumelo: ob zagonu je zapisalo crashkernel: memory value expected. Parameter odstrani s stikalom --remove-args.
• Zaganjanje grub2-mkconfig ni potrebno: grubby neposredno spremeni zagonske vnose. Preverjanje: sudo grubby --info=DEFAULT | grep args.

AlmaLinux 10

Koraki so enaki. V AlmaLinux 10 sta ukaz kdumpctl in storitev kdump v paketu kdump-utils; če ta ni nameščen (v preizkusu ga na cloud image ni bilo), kdump sploh ne teče in ni česa izklopiti.

Kdaj ga je smiselno obdržati?

Če se strežnik skrivnostno, brez sledi znova zažene ali zamrzne in želiš vzrok napake ugotoviti s podporo Red Hat, AlmaLinux ali proizvajalca programske opreme, je posnetek kdump (/var/crash) najpomembnejša sled. Takrat ga obdrži, vsaj do raziskave napake. Če je pomnilnika trajno premalo, namesto zmanjšanja rezervacije razmisli tudi o povečanju paketa VPS; o simptomih pomanjkanja pomnilnika piše članek Zmanjkalo je pomnilnika: OOM killer in datoteka swap.