Команда перезагрузки Linux: reboot, shutdown -r now, systemctl
- 8 ноября 2026 г.
- 09:00
- Автор: Adrien Roche
- Уроки
Команда перезагрузки в Linux: reboot, shutdown -r now и systemctl reboot
В любом современном дистрибутиве три команды ниже перезапускают машину абсолютно одинаково. Запускайте любую из них от root или через sudo; по SSH непривилегированная учётная запись получит Failed to reboot system via logind: Interactive authentication required.
sudo reboot
sudo shutdown -r now
sudo systemctl rebootЭто не три разные реализации. В дистрибутивах на systemd /sbin/reboot, /sbin/shutdown, /sbin/halt и /sbin/poweroff являются символическими ссылками на systemctl, который смотрит, под каким именем его вызвали, и переключается в соответствующий режим совместимости; ls -l $(which reboot) показывает эту ссылку. Какую бы форму вы ни набрали, systemd запускает reboot.target, останавливает все юниты в обратном порядке зависимостей, размонтирует файловые системы и просит ядро перезагрузиться. По SSH соединение рвётся через секунду-две; сколько машина будет недоступна, зависит от ядра, от проверки файловой системы и от загрузочного тракта провайдера, поэтому дайте ей минуту, прежде чем бить тревогу.
Выключение: shutdown -h now, poweroff, halt и устаревший init 6
Чтобы выключить машину, подойдёт любая из этих команд:
sudo shutdown -h now
sudo poweroff # identical to: sudo systemctl poweroffВ systemd -h означает "halt или выключение питания, смотря что выбрано по умолчанию", а по умолчанию это выключение питания, так что shutdown -h now и shutdown -P now идентичны. Подвох чаще всего в голом halt: он останавливает операционную систему, но не отправляет запрос на отключение питания, поэтому виртуальная машина застывает на System halted, оставаясь выделенной и тарифицируемой, пока вы не остановите её из панели. Используйте вместо этого halt -p, poweroff или shutdown -h now.
Формы из SysV всё ещё работают, потому что systemd отображает уровни выполнения на цели: init 6 и telinit 6 ведут к reboot.target, а init 0 ведёт к poweroff.target. В старом скрипте они безвредны, но не дают ни сообщения wall, ни планирования, ни записи в журнале, так что набирать их вручную смысла нет.
| Команда | Действие | Примечания |
|---|---|---|
reboot | Перезагрузка | Алиас для systemctl reboot |
shutdown -r now | Перезагрузка | Принимает время и сообщение wall |
systemctl reboot | Перезагрузка | Поддерживает --message= и --force |
shutdown -h now / poweroff | Выключение питания | -h равносильно -P в systemd |
halt | Остановка ОС, питание остаётся | Для выключения используйте halt -p |
init 6 / telinit 6 | Перезагрузка | Устаревшее, сопоставлено с reboot.target |
init 0 | Выключение питания | Устаревшее, сопоставлено с poweroff.target |
shutdown -c | Отмена запланированного выключения | Пользователи получают уведомление об отмене |
shutdown -k | Только отправка сообщения wall | Ничего на самом деле не выключается |
Планирование перезагрузки, её отмена и предупреждение пользователей
sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -cВременем может быть now, +m (через m минут) или hh:mm в 24-часовом формате (уже прошедшее сегодня время означает завтра). Без времени shutdown подразумевает +1: голый sudo shutdown выключит машину через шестьдесят секунд. Всё, что идёт после времени, рассылается как сообщение wall на все терминалы вошедших пользователей, а logind повторяет предупреждение по мере приближения срока; --no-wall отключает его, а shutdown -k отправляет предупреждение, ничего не планируя. За пять минут до срока logind создаёт /run/nologin, и новые входы в систему отклоняются.
shutdown -c отменяет отложенную операцию, удаляет /run/nologin и сообщает пользователям об отмене. Чтобы проверить, запланировано ли что-то, ищите /run/systemd/shutdown/scheduled: этот файл существует только пока операция в очереди и хранит режим и целевое время. Свежие версии systemd также принимают systemctl reboot --when=+10m с --when=show и --when=cancel (проверьте systemctl --help; в старых версиях этого нет).
Что происходит со службами и SSH-сеансами во время перезагрузки
Когда запрашивается reboot.target, systemd останавливает всё, что с ним конфликтует, то есть почти все юниты. Службы останавливаются в обратном порядке зависимостей: каждая выполняет свой ExecStop или получает SIGTERM, а если не завершилась за TimeoutStopSec (по умолчанию 90 секунд, из DefaultTimeoutStopSec= в /etc/systemd/system.conf), то получает SIGKILL. Именно этот таймаут виден на консоли как обратный отсчёт A stop job is running for ...; обычно это демон, игнорирующий SIGTERM, или база данных, которая ещё сбрасывает данные на диск. Затем файловые системы размонтируются или перемонтируются только на чтение, и ядро перезагружается. Запускать sync заранее не нужно.
Ваш SSH-сеанс не пользуется никакими привилегиями. ssh.service останавливается, scope с вашим сеансом получает SIGTERM, оболочка завершается, а клиент печатает Connection to 203.0.113.10 closed by remote host. Сервер tmux или screen защищает от обрыва связи, но не от перезагрузки: всё, что внутри него, тоже исчезнет.
Что вернётся после загрузки, определяется включённостью юнита, а не тем, что работало. Юниты со статусом enabled запускаются снова; всё, что было запущено вручную через systemctl start, процесс nohup или контейнер Docker без политики перезапуска, снова не запустится. Выполните systemctl list-unit-files --state=enabled до и systemctl --failed после; руководство о том, как выводить и фильтровать службы через systemctl, объясняет, как читать оба вывода.
Безопасная перезагрузка VPS: предполётный чек-лист
У VPS нет физического доступа, поэтому перезагрузка, после которой машина не вернулась, означает поход в консоль провайдера. Пять проверок, меньше минуты в сумме, предотвращают почти любой такой случай.
1. Убедитесь, что перезагрузка действительно нужна
Не каждое обновление требует её. В Ubuntu файл /var/run/reboot-required появляется, когда пакет запросил перезапуск, а /var/run/reboot-required.pkgs называет его; needrestart в Debian и Ubuntu и needs-restarting -r из dnf-utils в семействе RHEL делают то же самое. Новое ядро, glibc или systemd оправдывают перезагрузку; обновлённому nginx достаточно systemctl restart nginx. Сначала установите все ожидающие обновления, чтобы перезагрузиться один раз, а не два; разбор по теме обновления Ubuntu из командной строки описывает последовательность apt и флаг reboot-required.
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-* # running kernel vs. newest installed2. Убедитесь, что ничего не пишется прямо сейчас
Прерывание пакетного менеджера даёт самый быстрый способ получить наполовину настроенную систему, а прерванная на полпути резервная копия оказывается файлом, который вы потом примете за рабочую. Найдите такие процессы и посмотрите, кто ещё в системе:
pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w3. Проверьте конфигурацию, которая должна пережить загрузку
Три файла превращают рутинную перезагрузку в потерю доступа. Синтаксическая ошибка в sshd_config означает, что sshd не запустится и вы не войдёте: sudo sshd -t ничего не печатает, если файл корректен, и если вы недавно усиливали защиту демона SSH, запустите проверку сейчас. Запись в /etc/fstab для устройства, которого больше нет, уронит загрузку в аварийный режим, если у неё нет опции nofail; sudo findmnt --verify ловит большую часть таких проблем. Переполненный /boot может оставить наполовину установленное ядро, так что проверьте свободное место. Правила фаервола, написанные напрямую через iptables или nft и не сохранённые, исчезнут при перезагрузке; правила UFW и firewalld сохраняются.
sudo sshd -t
sudo findmnt --verify
df -h / /boot4. Снимите исходное состояние
systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt5. Перезагрузите и проверьте
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, чистый systemctl --failed и пустой diff означают, что перезагрузка прошла успешно.
Когда перезагрузка зависает: принудительный режим и когда пора в консоль провайдера
Если reboot вернул управление, но машина так и не выключается, значит застряла задача остановки; systemctl list-jobs покажет, какая именно. systemctl reboot --force пропускает упорядоченную остановку юнитов: процессы убиваются сразу, но файловые системы всё же размонтируются, так что это резко, но относительно безопасно. --force --force перезагружает немедленно, ничего не размонтируя, и может привести к потере данных; считайте это выдергиванием шнура из розетки. Интерфейс ядра SysRq остаётся последним рубежом, когда сам systemd уже не отвечает. Запись в /proc/sysrq-trigger всегда разрешена для root независимо от значения sysctl kernel.sysrq, но перенаправление должно выполняться от root, поэтому используйте root-оболочку или 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Обращайтесь к панели или консоли провайдера, когда гостевая система уже не может помочь себе сама: SSH недоступен после изменения сети или фаервола, ядро паникует при загрузке, аварийный режим из-за ошибки в fstab, забытый пароль root. Reboot или Shutdown в панели обычно отправляют событие питания ACPI, которое гость обрабатывает через logind (HandlePowerKey= в logind.conf), так что службы всё равно останавливаются корректно. Reset, Force stop или Power cycle обрезают виртуальное питание без предупреждения: журнал файловой системы проигрывается при следующей загрузке, но всё незаписанное теряется. Именно консоль VNC или последовательная консоль позволяет увидеть GRUB, сообщения ядра и аварийную оболочку, которых SSH никогда не покажет.
Проверка времени работы и последней перезагрузки
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-bootsuptime -s и who -b печатают время загрузки напрямую. last -x читает /var/log/wtmp и выводит записи как reboot, так и shutdown: строка reboot без предшествующей строки shutdown означает, что машина выключилась некорректно (паника ядра или жёсткий сброс). journalctl --list-boots нумерует все загрузки, известные журналу: 0 означает текущую, -1 означает предыдущую; journalctl -b -1 -e покажет последние строки перед предыдущим выключением, где оставляет след таймаут stop-задачи или убийство по OOM. Если в списке только текущая загрузка, журнал хранится в памяти: создайте /var/log/journal и перезапустите systemd-journald.
Каждая команда выше опирается на одно допущение: что если гостевая система не вернётся, у вас всё ещё есть доступ к ней. KVM Linux VPS с доступом к консоли даёт именно это: настоящую виртуальную машину со своим ядром, выделенным CPU и RAM, полным root-доступом и консолью на те дни, когда SSH не вариант. rdp.monster выдаёт её примерно через 10 секунд после подтверждения платежа, с безлимитным трафиком (fair-use), без KYC, с оплатой картой и криптовалютой, от $8.99/месяц.
Часто задаваемые вопросы
В чём разница между reboot и shutdown -r now?
systemctl, и обе запрашивают reboot.target, так что службы останавливаются в том же порядке, а диски размонтируются одинаково. Различие в том, что они принимают: shutdown берёт аргумент времени (+5, 02:30) и сообщение wall для вошедших пользователей, а reboot всегда немедленный. systemctl reboot добавляет --message= для журнала и --force для зависшей системы. Выбирайте то, что подходит к ситуации; результат идентичен.Безопасно ли выполнять reboot по SSH?
sshd_config без проверки sudo sshd -t: именно так машина возвращается в состоянии, в которое вы не сможете войти.Как перезагрузить Linux без sudo?
reboot работает без пароля. Удалённый SSH-сеанс не является локальным местом, так что на сервере команда завершается ошибкой Interactive authentication required. Используйте sudo reboot или добавьте учётную запись в sudoers с правилом, ограниченным /usr/bin/systemctl reboot, если хотите беспарольное, но узкое разрешение.Нужно ли выполнять sync перед перезагрузкой Linux?
reboot, shutdown и systemctl reboot проходят через штатную процедуру завершения systemd, которая останавливает службы, сбрасывает грязные буферы и размонтирует или перемонтирует файловые системы только на чтение перед передачей управления ядру. Запуск sync заранее безвреден, но избыточен. Он важен только перед путями, которые эту процедуру пропускают: systemctl reboot --force --force, жёсткий сброс из панели провайдера или echo b > /proc/sysrq-trigger, где рекомендуется порядок s (sync), затем u (перемонтировать только на чтение), затем b.
