RDP Monster

Perintah Reboot Linux: reboot, shutdown -r now, systemctl

Perintah Reboot Linux: reboot, shutdown -r now, systemctl

Perintah reboot Linux: reboot, shutdown -r now dan systemctl reboot

Pada distribusi mana pun yang aktual, tiga perintah di bawah ini menyalakan ulang mesin dengan cara yang persis sama. Jalankan salah satunya sebagai root atau melalui sudo; lewat SSH, akun tanpa hak istimewa akan mendapatkan Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Ini bukan tiga implementasi berbeda. Pada distribusi systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt dan /sbin/poweroff adalah symlink ke systemctl, yang memeriksa nama pemanggilnya lalu beralih ke mode kompatibilitas yang sesuai; ls -l $(which reboot) menampilkan tautan tersebut. Ejaan apa pun yang Anda ketik, systemd menjalankan reboot.target, menghentikan setiap unit dalam urutan dependensi terbalik, meng-unmount sistem berkas dan meminta kernel untuk restart. Lewat SSH koneksi terputus dalam satu atau dua detik; berapa lama mesin tidak dapat dijangkau bergantung pada kernel, pemeriksaan sistem berkas, dan jalur boot penyedia, jadi beri waktu satu menit sebelum menganggap ada masalah.

Mematikan mesin: shutdown -h now, poweroff, halt dan init 6 warisan lama

Untuk mematikan daya mesin, salah satu dari perintah berikut sudah cukup:

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

Di bawah systemd, -h berarti "halt atau power off, mana pun yang menjadi default", dan default-nya adalah power off, sehingga shutdown -h now dan shutdown -P now identik. Perintah yang sering menjebak adalah halt polos: ia menghentikan sistem operasi tetapi tidak pernah mengirim permintaan power-off, sehingga sebuah mesin virtual berhenti di System halted, tetap teralokasi dan tetap ditagih, sampai Anda menghentikannya dari panel. Gunakan halt -p, poweroff atau shutdown -h now sebagai gantinya.

Bentuk SysV masih berfungsi karena systemd memetakan runlevel ke target: init 6 dan telinit 6 mengarah ke reboot.target, init 0 ke poweroff.target. Keduanya tidak berbahaya dalam skrip lama, tetapi tidak menawarkan pesan wall, penjadwalan, maupun catatan di journal, jadi tidak ada alasan mengetiknya secara manual.

PerintahEfekCatatan
rebootMenyalakan ulangAlias dari systemctl reboot
shutdown -r nowMenyalakan ulangMenerima waktu dan pesan wall
systemctl rebootMenyalakan ulangMendukung --message= dan --force
shutdown -h now / poweroffMematikan daya-h sama dengan -P di systemd
haltMenghentikan OS, daya tetap menyalaGunakan halt -p untuk mematikan daya
init 6 / telinit 6Menyalakan ulangWarisan lama, dipetakan ke reboot.target
init 0Mematikan dayaWarisan lama, dipetakan ke poweroff.target
shutdown -cMembatalkan shutdown terjadwalPengguna menerima pemberitahuan pembatalan
shutdown -kHanya mengirim pesan wallTidak ada yang benar-benar dimatikan

Menjadwalkan reboot, membatalkannya dan memperingatkan pengguna yang sedang login

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

Waktunya bisa now, +m untuk m menit dari sekarang, atau hh:mm dalam format 24 jam (waktu yang sudah lewat hari ini berarti besok). Tanpa waktu sama sekali, shutdown mengasumsikan +1: perintah sudo shutdown polos mematikan mesin dalam enam puluh detik. Semua teks setelah waktu disiarkan sebagai pesan wall ke setiap terminal yang sedang login, dan logind mengulang peringatan saat tenggat mendekat; --no-wall membuatnya senyap, dan shutdown -k mengirim peringatan tanpa menjadwalkan apa pun. Lima menit sebelum tenggat, logind membuat /run/nologin, dan sejak saat itu login baru ditolak.

shutdown -c membatalkan operasi yang tertunda, menghapus /run/nologin dan memberi tahu pengguna yang login bahwa shutdown dibatalkan. Untuk memeriksa apakah ada yang tertunda, lihat /run/systemd/shutdown/scheduled: berkas itu hanya ada selama sebuah shutdown mengantre dan mencatat mode serta waktu targetnya. Rilis systemd terbaru juga menerima systemctl reboot --when=+10m, dengan --when=show dan --when=cancel (periksa systemctl --help; rilis lama tidak memilikinya).

Apa yang terjadi pada layanan dan sesi SSH saat reboot

Ketika reboot.target diminta, systemd menghentikan segala sesuatu yang berkonflik dengannya, yaitu hampir semua unit. Layanan berhenti dalam urutan dependensi terbalik: masing-masing menjalankan ExecStop-nya atau menerima SIGTERM, dan jika belum keluar setelah TimeoutStopSec (90 detik secara default, dari DefaultTimeoutStopSec= di /etc/systemd/system.conf) ia menerima SIGKILL. Batas waktu itulah hitung mundur A stop job is running for ... yang terlihat di konsol; biasanya berasal dari daemon yang mengabaikan SIGTERM atau basis data yang masih melakukan flush. Sistem berkas kemudian di-unmount atau di-remount hanya-baca dan kernel restart. Anda tidak perlu menjalankan sync terlebih dahulu.

Sesi SSH Anda tidak mendapat perlakuan khusus. ssh.service berhenti, scope yang menampung sesi login Anda menerima SIGTERM, shell Anda mati dan klien menampilkan Connection to 203.0.113.10 closed by remote host. Server tmux atau screen melindungi Anda dari koneksi yang putus, bukan dari reboot: apa pun yang berjalan di dalamnya juga hilang.

Apa yang kembali aktif ditentukan oleh status enablement, bukan oleh apa yang tadinya berjalan. Unit yang ditandai enabled akan start lagi; apa pun yang dijalankan manual dengan systemctl start, proses nohup atau kontainer Docker tanpa restart policy tidak akan kembali. Jalankan systemctl list-unit-files --state=enabled sebelumnya dan systemctl --failed sesudahnya; panduan tentang menampilkan dan memfilter layanan dengan systemctl menjelaskan cara membaca keduanya.

Me-reboot VPS dengan aman: daftar periksa pra-terbang

Pada VPS tidak ada akses fisik, jadi reboot yang tidak kembali berarti Anda harus memutar lewat konsol penyedia. Lima pemeriksaan, totalnya kurang dari satu menit, mencegah hampir semua situasi seperti itu.

1. Pastikan reboot memang diperlukan

Tidak setiap pembaruan memerlukannya. Di Ubuntu, /var/run/reboot-required ada ketika sebuah paket meminta restart dan /var/run/reboot-required.pkgs menyebut nama paketnya; needrestart di Debian dan Ubuntu, serta needs-restarting -r dari dnf-utils di keluarga RHEL, melakukan pemeriksaan yang sama. Kernel, glibc atau systemd baru membenarkan reboot; nginx yang baru ditambal hanya perlu systemctl restart nginx. Pasang dulu pembaruan yang tertunda agar Anda reboot sekali, bukan dua kali; panduan langkah demi langkah tentang memperbarui Ubuntu dari baris perintah membahas urutan apt dan penanda reboot-required.

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

2. Pastikan tidak ada proses yang sedang menulis

Menginterupsi manajer paket adalah jalan tercepat menuju sistem yang terkonfigurasi setengah jalan, dan cadangan yang terhenti di tengah jalan adalah berkas yang nanti akan Anda kira salinan yang baik. Cari proses-proses tersebut dan lihat siapa lagi yang sedang login:

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

3. Validasi konfigurasi yang harus bertahan setelah boot

Tiga berkas dapat mengubah reboot rutin menjadi terkunci di luar. Kesalahan sintaks di sshd_config membuat sshd tidak mau start dan Anda tidak bisa masuk kembali: sudo sshd -t tidak menampilkan apa pun bila berkasnya valid, dan jika Anda baru saja memperketat daemon SSH, jalankan sekarang. Entri /etc/fstab untuk perangkat yang sudah tidak ada akan menjatuhkan proses boot ke emergency mode kecuali entri itu memuat nofail; sudo findmnt --verify menangkap sebagian besar kasus itu. Partisi /boot yang penuh dapat meninggalkan kernel yang terpasang setengah jalan, jadi periksa ruang kosongnya. Aturan firewall yang ditulis langsung dengan iptables atau nft dan tidak pernah disimpan akan hilang saat reboot; aturan UFW dan firewalld tetap bertahan.

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

4. Ambil data awal sebagai pembanding

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

5. Reboot, lalu verifikasi

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

uname -r yang sesuai, systemctl --failed yang bersih dan diff kosong berarti reboot berjalan sebagaimana mestinya.

Ketika reboot menggantung: memaksanya, dan kapan sebaiknya memakai konsol penyedia

Jika reboot selesai dijalankan tetapi mesin tidak pernah mati, ada stop job yang macet; systemctl list-jobs menunjukkan yang mana. systemctl reboot --force melewati penghentian unit yang tertib: proses dimatikan begitu saja tetapi sistem berkas tetap di-unmount, jadi cara ini mendadak namun cukup aman. --force --force me-reboot seketika tanpa meng-unmount apa pun dan dapat menyebabkan kehilangan data; anggap saja seperti mencabut kabel listrik. Antarmuka SysRq milik kernel adalah upaya terakhir ketika systemd sendiri sudah tidak merespons. Menulis ke /proc/sysrq-trigger selalu diizinkan untuk root apa pun nilai sysctl kernel.sysrq, tetapi pengalihan (redirection) harus dijalankan sebagai root, jadi gunakan shell root atau sudo sh -c:

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

Gunakan panel atau konsol penyedia ketika guest sudah tidak bisa menolong dirinya sendiri: SSH tidak terjangkau setelah perubahan jaringan atau firewall, kernel yang panic saat boot, prompt emergency mode akibat baris fstab yang salah, atau kata sandi root yang terlupa. Reboot atau Shutdown di panel biasanya mengirim event daya ACPI yang ditangani guest melalui logind (HandlePowerKey= di logind.conf), sehingga layanan tetap berhenti dengan bersih. Reset, Force stop atau Power cycle memutus daya virtual tanpa peringatan: journal sistem berkas diputar ulang pada boot berikutnya, tetapi apa pun yang belum tertulis akan hilang. Konsol VNC atau serial itulah yang memungkinkan Anda melihat GRUB, pesan kernel dan emergency shell yang tidak pernah ditampilkan SSH.

Memeriksa uptime dan kapan mesin terakhir reboot

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 dan who -b mencetak waktu boot secara langsung. last -x membaca /var/log/wtmp dan menampilkan catatan reboot maupun shutdown: baris reboot tanpa baris shutdown sebelumnya berarti mesin mati secara tidak bersih (panic atau hard reset). journalctl --list-boots menomori setiap boot yang dikenal journal, 0 adalah boot saat ini dan -1 yang sebelumnya; journalctl -b -1 -e kemudian menampilkan baris-baris terakhir sebelum shutdown sebelumnya, tempat timeout stop-job atau kill karena kehabisan memori meninggalkan jejaknya. Jika hanya boot saat ini yang terdaftar, journal bersifat volatil: buat /var/log/journal lalu restart systemd-journald.

Semua perintah di atas bertumpu pada satu asumsi: bahwa ketika guest menolak kembali menyala, Anda masih bisa menjangkaunya. Sebuah VPS Linux KVM dengan akses konsol memberikan tepat itu, mesin virtual sungguhan dengan kernel sendiri, CPU dan RAM khusus, root penuh, serta konsol untuk hari-hari ketika SSH bukan pilihan. rdp.monster mengirimkannya sekitar 10 detik setelah pembayaran dikonfirmasi, dengan bandwidth tanpa batas (fair-use), tanpa KYC, menerima kartu dan kripto, mulai dari $8.99/bulan.

Pertanyaan yang sering ditanyakan

Apa perbedaan antara reboot dan shutdown -r now?

Pada sistem systemd tidak ada perbedaan praktis: keduanya berakhir menjalankan systemctl reboot.
Kedua perintah adalah symlink ke systemctl dan keduanya meminta reboot.target, sehingga layanan berhenti dalam urutan yang sama dan disk di-unmount dengan cara yang sama. Perbedaannya ada pada argumen yang mereka terima: shutdown menerima argumen waktu (+5, 02:30) dan pesan wall untuk pengguna yang sedang login, sedangkan reboot selalu langsung. systemctl reboot menambahkan --message= untuk journal dan --force untuk sistem yang macet. Pilih mana pun yang sesuai dengan situasi; hasilnya identik.

Apakah aman menjalankan reboot lewat SSH?

Ya. Koneksi terputus saat sshd berhenti, tetapi reboot berlanjut tanpa Anda.
Reboot ditangani oleh systemd, bukan oleh shell Anda, jadi kehilangan sesi SSH di tengah jalan tidak menginterupsinya. Anda akan melihat Connection closed by remote host dalam beberapa detik dan bisa terhubung kembali setelah mesin menyala. Yang tidak aman adalah me-reboot saat instalasi paket, cadangan atau dump basis data masih berjalan, atau setelah mengedit sshd_config tanpa memeriksanya dengan sudo sshd -t: itulah kasus-kasus ketika mesin kembali dalam keadaan yang tidak bisa Anda masuki.

Bagaimana cara reboot Linux tanpa sudo?

Lewat SSH tidak bisa; hanya pengguna yang login di konsol lokal yang mungkin diizinkan oleh polkit.
systemd bertanya kepada polkit apakah pemanggil boleh melakukan reboot. Aturan default mengizinkan pengguna dengan sesi lokal aktif dan tanpa pengguna lain yang login, itulah sebabnya reboot berfungsi tanpa kata sandi di laptop. Sesi SSH jarak jauh bukan seat lokal, jadi di server perintah tersebut gagal dengan Interactive authentication required. Gunakan sudo reboot, atau tambahkan akun ke berkas sudoers dengan aturan yang terbatas pada /usr/bin/systemctl reboot jika Anda menginginkan izin tanpa kata sandi namun sempit.

Apakah perlu menjalankan sync sebelum reboot Linux?

Tidak. Reboot normal melakukan flush dan meng-unmount setiap sistem berkas sebelum kernel restart.
reboot, shutdown dan systemctl reboot semuanya melewati urutan shutdown systemd, yang menghentikan layanan, menyinkronkan buffer kotor dan meng-unmount atau me-remount sistem berkas menjadi hanya-baca sebelum menyerahkan kendali ke kernel. Menjalankan sync lebih dulu tidak berbahaya tetapi mubazir. Hal itu baru penting sebelum jalur yang melewati urutan tersebut: systemctl reboot --force --force, hard reset dari panel penyedia, atau echo b > /proc/sysrq-trigger, di mana urutan yang disarankan adalah s (sync), lalu u (remount hanya-baca), lalu b.

Adrien Roche, Editor Infrastruktur & Hosting

Insinyur sistem yang sudah 10+ tahun mengelola server Windows Server dan Linux. Adrien mengurus dokumentasi infrastruktur rdp.monster dan menulis panduan kami tentang RDP, hosting VPS, administrasi server, jaringan, dan tool privasi.

Gabung program reseller kami

Data Anda

Jika Anda punya pertanyaan, klik di sini untuk menghubungi kami !
Nama(Wajib)
Masukkan alamat email Anda, pastikan Anda sudah punya akun di dashboard.rdp.monster !

Perusahaan Anda

Masukkan alamat situs web Anda jika ada
Ceritakan singkat cara Anda menjual layanan ke pelanggan. Misalnya, lewat obrolan di forum.

Bahkan monster pun suka cookie!

Kami memakai cookie agar penjelajahan Anda lebih nyaman, untuk menampilkan iklan atau konten yang dipersonalisasi, dan untuk menganalisis lalu lintas kami. Dengan mengklik “Terima”, Anda menyetujui penggunaan cookie oleh kami.