Linux Yeniden Başlatma Komutu: reboot, shutdown -r now, systemctl

Linux yeniden başlatma komutu: reboot, shutdown -r now ve systemctl reboot

Güncel her dağıtımda aşağıdaki üç komut makineyi tamamen aynı şekilde yeniden başlatır. Bunlardan birini root olarak ya da sudo ile çalıştırın; SSH üzerinden yetkisiz bir hesap Failed to reboot system via logind: Interactive authentication required hatasını alır.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Bunlar üç ayrı uygulama değildir. systemd dağıtımlarında /sbin/reboot, /sbin/shutdown, /sbin/halt ve /sbin/poweroff, systemctl'e giden sembolik bağlantılardır; systemctl hangi adla çağrıldığını kontrol eder ve ilgili uyumluluk moduna geçer; ls -l $(which reboot) bu bağlantıyı gösterir. Hangi yazımı kullanırsanız kullanın, systemd reboot.target hedefini başlatır, tüm birimleri ters bağımlılık sırasıyla durdurur, dosya sistemlerini ayırır ve çekirdekten yeniden başlatmasını ister. SSH üzerinde bağlantı bir iki saniye içinde düşer; makinenin ne kadar süre erişilemez kalacağı çekirdeğe, olası bir dosya sistemi kontrolüne ve sağlayıcının açılış yoluna bağlıdır; bu yüzden sorun olduğunu varsaymadan önce bir dakika bekleyin.

Kapatma: shutdown -h now, poweroff, halt ve eski init 6

Makineyi kapatmak için aşağıdakilerden biri yeterlidir:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

systemd altında -h "halt ya da power off, hangisi varsayılansa" anlamına gelir ve varsayılan kapatmadır; dolayısıyla shutdown -h now ile shutdown -P now aynıdır. Kullanıcıları yanıltan komut düz halt'tır: işletim sistemini durdurur ama kapatma isteğini hiç göndermez; böylece sanal makine System halted ekranında, hala tahsisli ve hala faturalandırılır halde, siz panelden durdurana kadar bekler. Onun yerine halt -p, poweroff veya shutdown -h now kullanın.

SysV biçimleri hala çalışır, çünkü systemd çalışma seviyelerini hedeflere eşler: init 6 ve telinit 6, reboot.target'e; init 0 ise poweroff.target'e karşılık gelir. Eski bir betikte zararsızdırlar ama wall mesajı, zamanlama ve journal kaydı sunmazlar; bu yüzden elle yazmak için bir neden yoktur.

Yeniden başlatmayı zamanlama, iptal etme ve kullanıcıları uyarma

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

Saat değeri now, şu andan itibaren m dakika için +m ya da 24 saat biçiminde hh:mm olabilir (bugün için geçmiş bir saat yarın anlamına gelir). Hiç saat verilmezse shutdown +1 varsayar: yalın bir sudo shutdown makineyi altmış saniye içinde kapatır. Saatten sonraki her şey, oturum açmış tüm terminallere wall mesajı olarak yayınlanır ve logind son tarih yaklaştıkça uyarıyı tekrarlar; --no-wall bunu susturur, shutdown -k ise hiçbir şey zamanlamadan yalnızca uyarıyı gönderir. Son tarihten beş dakika önce logind /run/nologin dosyasını oluşturur ve o andan itibaren yeni oturum açmalar reddedilir.

shutdown -c bekleyen işlemi iptal eder, /run/nologin dosyasını kaldırır ve oturum açmış kullanıcılara kapatmanın iptal edildiğini bildirir. Bekleyen bir işlem olup olmadığını anlamak için /run/systemd/shutdown/scheduled dosyasına bakın: yalnızca kuyrukta bir kapatma varken bulunur ve modu ile hedef saati kaydeder. Yeni systemd sürümleri ayrıca systemctl reboot --when=+10m komutunu, --when=show ve --when=cancel ile birlikte kabul eder (systemctl --help çıktısını kontrol edin; eski sürümlerde yoktur).

Yeniden başlatma sırasında servislere ve SSH oturumlarına ne olur

reboot.target istendiğinde systemd onunla çakışan her şeyi durdurur, ki bu neredeyse tüm birimlerdir. Servisler ters bağımlılık sırasıyla durur: her biri ExecStop komutunu çalıştırır ya da SIGTERM alır; TimeoutStopSec (varsayılan 90 saniye, /etc/systemd/system.conf içindeki DefaultTimeoutStopSec= değerinden) süresi sonunda hala çıkmamışsa SIGKILL alır. Konsolda görülen A stop job is running for ... geri sayımı işte bu zaman aşımıdır; genellikle SIGTERM'i yok sayan bir arka plan servisi ya da hala veri yazan bir veritabanı söz konusudur. Ardından dosya sistemleri ayırılır veya salt okunur olarak yeniden bağlanır ve çekirdek yeniden başlar. Önceden sync çalıştırmanıza gerek yoktur.

SSH oturumunuz özel bir muamele görmez. ssh.service durur, oturumunuzu tutan scope SIGTERM alır, kabuğunuz sonlanır ve istemci Connection to 203.0.113.10 closed by remote host yazar. tmux ya da screen sunucusu sizi kopan bir bağlantıdan korur, yeniden başlatmadan değil: içinde çalışan her şey de gider.

Geri neyin geleceğini çalışıyor olması değil, etkinleştirilmiş olması belirler. enabled işaretli birimler yeniden başlar; systemctl start ile elle başlatılanlar, bir nohup süreci veya yeniden başlatma politikası olmayan bir Docker konteyneri başlamaz. Öncesinde systemctl list-unit-files --state=enabled, sonrasında systemctl --failed çalıştırın; systemctl ile servisleri listeleme ve filtreleme rehberi ikisinin de nasıl okunacağını anlatır.

Bir VPS'i güvenle yeniden başlatmak: ön kontrol listesi

VPS'te fiziksel erişim olmadığı için geri gelmeyen bir yeniden başlatma sizi sağlayıcının konsoluna götürür. Toplamda bir dakikadan kısa süren beş kontrol, bu durumların neredeyse tamamını önler.

1. Yeniden başlatmanın gerçekten gerekli olduğunu doğrulayın

Her güncelleme yeniden başlatma gerektirmez. Ubuntu'da bir paket yeniden başlatma istediğinde /var/run/reboot-required oluşur ve /var/run/reboot-required.pkgs ilgili paketi listeler; Debian ve Ubuntu'da needrestart, RHEL ailesinde dnf-utils içindeki needs-restarting -r aynı kontrolü yapar. Yeni bir çekirdek, glibc veya systemd yeniden başlatmayı haklı kılar; yamalanmış bir nginx için systemctl restart nginx yeterlidir. İki kez değil bir kez yeniden başlatmak için önce bekleyen güncellemeleri kurun; Ubuntu'yu komut satırından güncelleme rehberi apt sırasını ve reboot-required işaretini anlatır.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. Yazımı süren bir işlem olmadığından emin olun

Bir paket yöneticisini yarıda kesmek, yarım yapılandırılmış bir sisteme giden en kısa yoldur; yarıda kesilen bir yedek ise ileride iyi bir kopya sandığınız dosya olur. Bu süreçleri arayın ve başka kimin oturum açtığını görün:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Açılışı atlatması gereken yapılandırmayı doğrulayın

Üç dosya, rutin bir yeniden başlatmayı sisteme kilitlenmeye çevirir. sshd_config içindeki bir sözdizimi hatası sshd'nin başlamaması ve sisteme geri dönememeniz demektir: dosya geçerliyse sudo sshd -t hiçbir şey yazdırmaz; yakın zamanda SSH sunucusunu sertleştirdiyseniz bu komutu şimdi çalıştırın. Artık var olmayan bir cihaz için yazılmış bir /etc/fstab satırı, nofail içermiyorsa açılışı acil durum moduna düşürür; sudo findmnt --verify bunun çoğunu yakalar. Dolu bir /boot yarım kurulmuş bir çekirdek bırakabilir, bu yüzden boş alanını kontrol edin. Doğrudan iptables veya nft ile yazılmış ve hiç kaydedilmemiş güvenlik duvarı kuralları yeniden başlatmada kaybolur; UFW ve firewalld kuralları kalıcıdır.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Bir referans anlık görüntü alın

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Yeniden başlatın, sonra doğrulayın

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

Beklenen bir uname -r çıktısı, temiz bir systemctl --failed ve boş bir fark, yeniden başlatmanın işini yaptığı anlamına gelir.

Yeniden başlatma takıldığında: zorlama ve sağlayıcı konsolunu kullanma zamanı

reboot komutu geri döndüğü halde makine kapanmıyorsa takılmış bir durdurma işi vardır; hangisi olduğunu systemctl list-jobs gösterir. systemctl reboot --force düzenli birim kapatma aşamasını atlar: süreçler doğrudan sonlandırılır ama dosya sistemleri yine de ayırılır, yani sert ama makul ölçüde güvenlidir. --force --force hiçbir şeyi ayırmadan anında yeniden başlatır ve veri kaybına yol açabilir; bunu fişi çekmek gibi düşünün. Çekirdeğin SysRq arayüzü, systemd artık yanıt vermediğinde son çaredir. /proc/sysrq-trigger dosyasına yazmak, kernel.sysrq sysctl değeri ne olursa olsun root için her zaman mümkündür; ancak yönlendirmenin root olarak çalışması gerekir, bu yüzden bir root kabuğu veya sudo sh -c kullanın:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Konuk sistem kendine yardım edemez hale geldiğinde sağlayıcının paneline ya da konsoluna başvurun: bir ağ veya güvenlik duvarı değişikliğinden sonra erişilemeyen SSH, açılışta panik veren bir çekirdek, hatalı bir fstab satırından gelen acil durum istemi, unutulmuş bir root parolası. Bir paneldeki Reboot veya Shutdown genellikle konuk sistemin logind aracılığıyla işlediği bir ACPI güç olayı gönderir (logind.conf içindeki HandlePowerKey=), yani servisler yine düzgün durur. Reset, Force stop veya Power cycle ise sanal gücü uyarısız keser: dosya sistemi günlüğü sonraki açılışta yeniden işlenir ama yazılmamış her şey kaybolur. VNC veya seri konsol, SSH'ın size hiçbir zaman göstermediği GRUB ekranını, çekirdek mesajlarını ve acil durum kabuğunu izlemenizi sağlar.

Çalışma süresini ve son yeniden başlatma zamanını kontrol etme

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s ve who -b açılış zamanını doğrudan yazdırır. last -x, /var/log/wtmp dosyasını okur ve hem reboot hem shutdown kayıtlarını listeler: öncesinde shutdown satırı olmayan bir reboot satırı, makinenin düzgün kapanmadığı (panik ya da sert sıfırlama) anlamına gelir. journalctl --list-boots journal'ın bildiği her açılışı numaralandırır; 0 mevcut olanı, -1 bir öncekini gösterir; journalctl -b -1 -e ise önceki kapatmadan hemen önceki satırları gösterir; bir durdurma işi zaman aşımı ya da bellek yetersizliği sonlandırması izini orada bırakır. Yalnızca mevcut açılış listeleniyorsa journal geçicidir: /var/log/journal dizinini oluşturun ve systemd-journald servisini yeniden başlatın.

Yukarıdaki her komut tek bir varsayıma dayanır: konuk sistem geri gelmediğinde ona hala ulaşabilmeniz. Konsol erişimli KVM Linux VPS tam olarak bunu sunar: kendi çekirdeği, ayrılmış CPU ve RAM'i, tam root yetkisi olan gerçek bir sanal makine ve SSH'ın seçenek olmadığı günler için bir konsol. rdp.monster, ödeme onaylandıktan yaklaşık 10 saniye sonra teslim eder; sınırsız (adil kullanım) bant genişliği, KYC yok, kart ve kripto kabul edilir, aylık $8.99'dan başlar.