Rocky Linux 및 AlmaLinux 재부팅 필요 여부 확인 방법

Rocky Linux와 AlmaLinux에서 재부팅이 필요한 업데이트

Rocky Linux와 AlmaLinux에서 dnf update는 디스크에 새 파일을 기록하고 작업을 마칩니다. 현재 부팅된 커널은 그대로 실행 중인 상태입니다. 이미 라이브러리를 연 모든 프로세스는 해당 라이브러리가 닫힐 때까지 이전 파일을 계속 사용합니다. Linux는 마지막 프로세스가 종료될 때까지 디스크에서 이전 파일을 유지하기 때문입니다. 따라서 시스템은 업데이트가 적용된 코드를 실행 중임에도 불구하고 사용 가능한 업데이트가 없다고 보고할 수 있습니다. 두 배포판 모두 동일한 Red Hat 소스를 기반으로 재빌드되므로 이 과정은 차이가 없습니다. 또한 Rocky와 Alma 사이의 선택은 여기서 다루는 내용보다는 호환성 보장이나 CPU 지원 여부에 따라 결정됩니다. 아래 명령어는 CentOS 서버에서 사용하던 것과 동일하며, 이는 우연이 아닙니다. 두 프로젝트 모두 2020년 Stream 발표 이후 CentOS의 대체제로 구축되었기 때문입니다.

어떤 업데이트가 재부팅을 필요로 하고, 어떤 업데이트가 서비스 재시작만으로 충분한지는 시스템에 직접 확인해야 합니다. 이를 확인하는 명령어는 needs-restarting입니다. 업데이트는 세 단계로 분류됩니다. 커널과 일부 핵심 패키지는 전체 재부팅이 필요합니다. 일반적인 라이브러리 업데이트는 해당 라이브러리를 사용하는 서비스를 재시작해야 합니다. 그 외의 나머지 업데이트는 RPM 작업이 완료되는 즉시 적용됩니다.

needs-restarting 설치

needs-restarting는 DNF 플러그인입니다. 이 플러그인은 dnf-plugins-core에 포함되어 있으며, 대부분의 Rocky 및 Alma 설치 환경에는 이미 존재합니다. /usr/bin/needs-restarting 명령어는 yum-utils에 포함된 작은 래퍼(wrapper)이며, dnf-utils이라는 이름으로도 호출할 수 있습니다.

sudo dnf install -y yum-utils
needs-restarting --help

두 명령어 모두 동일한 코드를 실행합니다. 래퍼가 DNF 하위 명령어를 호출하기 때문입니다.

needs-restarting -r
dnf needs-restarting -r

두 패키지 모두 배포판 자체 저장소에서 제공되므로, 이를 위해 EPEL 또는 CRB 저장소 활성화가 필요하지 않습니다.

Rocky Linux 10 및 AlmaLinux 10 계열은 여전히 DNF 4를 사용합니다. 2026-10-12 기준으로, 두 BaseOS 저장소 모두 dnf 4.20.0을 dnf-plugins-core 4.7.0 및 yum-utils와 함께 제공하며, dnf5 패키지는 없습니다. 따라서 해당 환경의 needs-restarting은 이 문서에서 설명하는 dnf-plugins-core 플러그인과 동일하며, 아래의 모든 내용이 적용됩니다. 여기에는 재부팅 알림과 종료 코드를 생성하는 -r도 포함되므로, 스크립트 작성 시 이를 유지하십시오. Rocky 및 Alma 9는 더 구버전인 dnf-plugins-core 4.3.0 빌드를 사용하며, 두 빌드의 동작이 다른 몇 가지 지점은 아래에 별도로 표시되어 있습니다.

1단계: 재부팅이 필요한 업데이트

먼저 재부팅 확인을 실행합니다. 이 작업은 RPM 데이터베이스와 시스템 부팅 시간만 읽으므로 속도가 빠르며 root 권한이 필요하지 않습니다.

needs-restarting -r

부팅 이후 중요한 변경 사항이 없으면 다음과 같이 두 줄을 출력합니다.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

변경 사항이 있으면 Core libraries or services have been updated since boot-up:를 출력한 뒤 발견된 패키지 이름을 나열하고, 마지막으로 다음을 출력합니다.

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

종료 코드도 동일한 결과를 나타냅니다. 재부팅이 필요 없으면 0, 필요하면 1을 반환합니다. 스크립트 작성 시 이 종료 코드를 활용하십시오.

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

여기서 종료 코드 1은 실패가 아닌 정상적인 응답입니다. set -e 환경에서 보호 장치 없는 needs-restarting -r을 사용하면 해당 줄에서 스크립트가 종료되므로, 위 예시처럼 if로 감싸야 합니다.

재부팅 알림을 유발하는 패키지는 플러그인 내부에 하드코딩된 짧은 목록에 정의되어 있습니다. Rocky Linux 10 및 AlmaLinux 10 빌드에는 kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl가 포함되어 있습니다. Rocky 및 Alma 9 빌드에는 kernel-core가 제외된 동일한 목록이 들어 있으며, 이는 다음 섹션에서 설명할 이유로 중요합니다. 추측하지 말고 직접 확인하십시오.

목록의 각 항목은 명확한 이유가 있습니다. 새로운 kernel 패키지는 /boot 및 /lib/modules에 파일만 기록하며, 실행 중인 커널은 교체할 수 없으므로 재부팅 전까지는 아무것도 변경되지 않습니다. 시스템의 거의 모든 사용자 공간 프로세스는 glibc에 링크되어 있으며, 여기에는 PID 1도 포함됩니다. 따라서 "영향받는 서비스 재시작"은 PID 1까지 재시작해야 함을 의미하며, 재부팅이 이를 수행하는 안전한 방법입니다. dbus와 dbus-broker는 시스템의 모든 클라이언트 연결을 처리하므로, 실행 중인 시스템에서 버스를 중단하면 통신 중인 클라이언트가 모두 끊깁니다. linux-firmware과 microcode_ctl은 부팅 시 로드됩니다. VPS 환경에서 마이크로코드 부분은 일반적으로 하이퍼바이저 호스트가 물리 CPU를 제어하므로 사용자가 관찰할 수 있는 변화를 일으키지 않습니다.

사용자 정의 패키지를 추가할 수도 있습니다. /etc/dnf/plugins/needs-restarting.d/ 아래의 모든 .conf 파일은 패키지 이름 목록으로 읽히며(줄당 하나씩), 해당 이름들이 재부팅 목록에 추가됩니다.

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

이는 수정이 아닌 정책적 선택입니다. "TLS 라이브러리가 변경되면, 이를 사용하는 모든 서비스를 일일이 찾아내는 대신 재부팅을 수행하겠다"는 의미입니다.

재부팅 알림이 도출되는 원리

needs-restarting -r은 현재 실행 중인 커널 버전과 최신 설치된 커널 버전을 비교하지 않습니다. 대신 타임스탬프를 비교합니다. 핵심 목록에 있는 모든 패키지에 대해 RPM 설치 시간을 읽고 시스템 부팅 시간과 비교합니다. 핵심 패키지가 마지막 부팅 이후에 설치되었다면 "재부팅 필요"라는 결과가 나옵니다. 부팅 시간은 systemd의 UnitsLoadStartTimestamp이 D-Bus를 통해 제공될 때는 이를 사용하며, 그렇지 않은 경우에는 /proc/1의 수정 시간과 /proc/stat의 btime 필드 중 더 나중의 시간을 사용합니다.

이 메커니즘에는 알아두어야 할 결과가 하나 있습니다. 커널을 설치하고 재부팅했으나 부팅 기본값이 고정되어 있어 이전 커널로 부팅된 경우, 설치 시간이 부팅 시간보다 이전이 되므로 needs-restarting -r는 아무런 알림을 보내지 않습니다. 도구는 자신의 질문에 올바르게 답하고 있는 것이지만, 사용자가 의도한 질문과는 다를 수 있습니다. 커널은 별도로 확인하십시오.

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

첫 번째 명령은 현재 실행 중인 커널을 출력합니다. rpm -q --last kernel의 첫 번째 줄은 가장 최근에 설치된 커널입니다. grubby --default-kernel은 다음 부팅 시 부트로더가 선택할 커널을 출력합니다. 이 세 가지 결과가 일치하지 않는다면, 콘솔로 접근할 수 없는 장비를 재부팅하기 전에 부팅 기본값을 수정하십시오.

Rocky 및 Alma 9에는 또 다른 간극이 있습니다. 해당 빌드 플러그인은 kernel을 감시하지만 kernel-core는 감시하지 않기 때문에, kernel 패키지 없이 kernel-core을 업데이트하는 트랜잭션이 발생하면 새로운 커널이 설치되어도 실행되지 않은 상태에서 needs-restarting -r는 재부팅이 필요 없다고 보고합니다. Red Hat은 Enterprise Linux 9에서 이러한 동작을 문서화하고 있습니다. kernel 패키지가 설치된 시스템에서 일상적인 dnf update을 수행하면 해당 패키지도 함께 업데이트되므로 알림이 정상적으로 작동합니다. 확인하려면 rpm -q kernel를 실행하십시오. 만약 패키지가 설치되어 있지 않다는 메시지가 나오면, 해당 시스템에서는 재부팅 알림이 커널 업데이트를 감지하지 못하므로 대신 uname -r과 rpm -q --last kernel-core을 비교해야 합니다.

2단계: 서비스 재시작이 필요한 업데이트

RPM이 공유 라이브러리를 교체할 때, 기존 파일을 언링크(unlink)하고 새 파일을 작성합니다. 이미 해당 파일을 매핑한 프로세스는 이전 inode를 계속 유지하며 기존 코드를 실행합니다. openssl-libs은 가장 중요한 사례입니다. libcrypto의 수정 사항은 웹 서버를 재시작해야만 웹 서버에 적용됩니다.

sudo needs-restarting -s

이 명령은 서비스 시작 이후 해당 서비스의 파일이나 의존성 파일이 업데이트된 systemd 서비스를 나열합니다. sudo을 사용하십시오. root 권한이 없으면 이 도구는 사용자의 프로세스에 대한 /proc 항목만 읽을 수 있으므로, 결과가 실제보다 적게 보고되어 목록이 짧게 나타날 수 있습니다.

sudo needs-restarting
sudo needs-restarting --exclude-services

첫 번째 명령은 영향을 받는 모든 프로세스의 PID와 명령줄을 출력합니다. 두 번째 명령은 systemd 서비스가 이미 처리 중인 항목을 제외하므로, 로그인 셸, tmux 세션, cron 작업 및 수동으로 시작한 항목만 남습니다. 이러한 프로세스는 스스로 재시작되지 않습니다. --exclude-services은 Rocky 및 Alma 10 빌드에만 존재합니다. 9 버전에는 해당 옵션이 없으므로 전체 sudo needs-restarting 목록을 읽고 -s 출력에 포함된 서비스에 속한 프로세스를 제외하십시오.

dbus-broker.service과 같이 재부팅이 필요한 패키지에 속한 서비스는 목록에 있더라도 재시작하지 마십시오. 대신 재부팅을 수행하십시오. 2026-10-12 기준으로 Rocky Linux 및 AlmaLinux 빌드는 여전히 이러한 서비스를 다른 서비스와 동일하게 출력합니다. CentOS Stream 10 패키지는 2026년 7월에 변경되어 해당 서비스를 목록에서 제외하고 대신 stderr에 Warning: The following services should not be restarted but require a reboot:을 출력합니다. 사용하는 릴리스에 이 변경 사항이 적용되면 해당 경고를 그대로 따르십시오.

나머지 서비스는 하나씩 재시작하고, 다음 서비스로 넘어가기 전에 각각 정상 작동 여부를 확인하십시오.

sudo systemctl restart nginx
systemctl status nginx

목록을 systemctl restart으로 파이프하지 마십시오. 현재 사용 중인 SSH 세션이 그 이유입니다. RHEL 계열에서 sshd.service는 KillMode=process과 함께 제공되므로, 이를 재시작하면 리스닝 데몬에 신호를 보내고 연결별 프로세스는 그대로 두어 열려 있는 세션이 유지됩니다. 자신의 서버에서 systemctl cat sshd | grep KillMode로 이를 확인하고, 처음 수행할 때는 항상 두 번째 세션을 열어 두십시오.

DNF 없이도 동일한 프로세스를 찾을 수 있으며, 이는 관련된 파일 경로를 확인해야 할 때 유용합니다.

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL는 디스크에서 삭제된 매핑 파일을 표시합니다. 조치를 취하기 전에 경로를 읽어 보십시오. 삭제된 임시 파일과 메모리 기반 파일도 여기에 나타나며, 이는 서비스를 재시작해야 할 이유가 되지 않습니다.

Tier 3: 기타 모든 항목

대부분의 업데이트는 이 범주에 속하며 별도의 조치가 필요하지 않습니다. curl, tar, vim 또는 dnf 자체와 같이 명령어가 시작될 때만 파일이 읽히는 패키지는 RPM 작업이 완료되면 즉시 적용됩니다. 다음 실행 시 새로운 바이너리를 읽기 때문입니다. 설정 파일, 스크립트, 문서 및 데이터 패키지도 동일하게 동작합니다. needs-restarting은 이러한 패키지를 언급하지 않으며, 이는 탐지 누락이 아니라 정상적인 동작입니다.

이 계층에서 유일하게 주의할 점은 지속 시간입니다. 업데이트 이전에 시작된 프로세스는 패키지의 중요도와 관계없이 종료될 때까지 이전 실행 파일을 계속 사용합니다. 바로 이 문제를 해결하기 위해 sudo needs-restarting --exclude-services이 존재하며, 9 버전에서는 간단히 sudo needs-restarting를 사용할 수 있습니다.

dnf-automatic을 사용하는 장비에 적용되지 않은 수정 사항이 수주 동안 남아 있는 이유

이 지점에서 세 가지 계층은 단순한 상식이 아닌 중요한 문제가 됩니다. dnf-automatic을 이용한 자동 업데이트는 타이머에 따라 패키지를 설치하며, /etc/dnf/automatic.conf의 기본 reboot 설정은 never입니다. apply_updates = yes 및 reboot = never 설정을 사용하면 장비는 6주 동안 6개의 커널 업데이트와 glibc 수정 사항을 설치할 수 있지만, 여전히 0주 차에 부팅했던 커널과 C 라이브러리로 동작하게 됩니다. 업데이트 로그는 완벽해 보이지만, 실제 실행 중인 시스템에는 아무것도 적용되지 않은 상태입니다.

해결책은 /etc/dnf/automatic.conf에 세 줄을 추가하는 것입니다.

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot는 never, when-changed, when-needed 값을 허용합니다. never은 기본값이며 모든 결정을 사용자에게 맡깁니다. when-changed는 패키지를 변경하는 트랜잭션이 발생한 후 무조건 재부팅을 수행하는데, 이는 투박하지만 예측 가능한 방식입니다. when-needed은 방금 적용된 트랜잭션에 재부팅이 필요한지 DNF에 확인하므로, 사용자 공간(userspace)만 업데이트되는 경우에는 재부팅 없이 넘어갑니다. reboot_command은 실제로 실행되는 설정이며, 기본값은 로그인한 사용자에게 5분간의 경고를 제공합니다. random_sleep와 타이머 일정을 설정하여 장비가 다시 정상적으로 올라오는 것을 확인할 수 있는 시간대에 재부팅이 이루어지도록 하십시오.

systemctl list-timers 'dnf-*'을 사용하여 어떤 유닛을 활성화했는지 확인하십시오. dnf-automatic에는 여러 변형이 포함되어 있으며 동작 방식이 모두 다르므로, 설정 파일만으로는 무엇이 실행되는지 알 수 없습니다.

예약된 작업이 실행된 후에는 로그를 확인하기보다 장비에 직접 물어보십시오.

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

재부팅 시간을 예약할 수 없는 상황이라면, VPS에서의 라이브 커널 패치가 다른 대안이 될 수 있습니다. 이 방식은 재부팅 없이 실행 중인 커널에 특정 커널 수정 사항을 적용합니다. 이는 커널 문제의 일부만 해결하며 glibc나 서비스에는 아무런 영향을 주지 않으므로, 재부팅을 완전히 없애는 것이 아니라 재부팅 주기를 늘리는 수단으로 활용하십시오. 재부팅을 수행할 때는 의도적으로 진행하고 장비가 응답할 때까지 로그인 상태를 유지하십시오. 커널 업데이트는 장비가 다시 부팅되지 않는 가장 흔한 원인이기 때문입니다. 콘솔 접근 권한이 없는 장비를 재부팅하기 전에 커널 업데이트 후 VPS가 부팅되지 않을 때의 대처법을 읽어보고, 재부팅 확인 절차를 정기 서버 유지보수 체크리스트에 포함하여 사고가 발생한 뒤에야 떠올리는 일이 없도록 하십시오.

Ubuntu 및 Debian에서의 동일한 작업

혼합된 환경에서는 이에 상응하는 도구가 필요합니다. Ubuntu와 Debian에서 재부팅 플래그는 명령어가 아니라 파일입니다. 패키지 스크립트가 /run/reboot-required를 생성하며, /run/reboot-required.pkgs 파일에는 재부팅을 요청한 패키지 목록이 기록됩니다. 따라서 [ -f /run/reboot-required ]는 needs-restarting -r와 동일한 역할을 합니다. 구형 문서에서는 /var/run/reboot-required를 언급하기도 하는데, /var/run가 /run를 가리키는 심볼릭 링크이므로 이는 같은 파일입니다. 서비스 측면에서는 최신 Ubuntu Server 릴리스에 기본 설치되는 needrestart를 사용합니다. 이 서비스는 apt upgrade 중에 실행되며, 아무것도 변경하지 않고 재시작이 필요한 항목만 나열하려면 sudo needrestart -r l를 단독으로 실행하면 됩니다. 자동 업데이트 공백 문제도 동일하며 해결 방법 또한 같습니다. Ubuntu의 unattended-upgrades 설정 시 /etc/apt/apt.conf.d/50unattended-upgrades 파일에 Unattended-Upgrade::Automatic-Reboot "true"; 및 Unattended-Upgrade::Automatic-Reboot-Time "02:00";을 추가하면 됩니다.

실패 유형 및 확인 방법

• needs-restarting: command not found은 yum-utils이 설치되지 않았음을 의미합니다. 이를 설치하거나, dnf-plugins-core이 존재하는 즉시 작동하는 dnf needs-restarting를 대신 호출하십시오.
• 재부팅 확인 단계에서 오류 메시지 없이 멈추는 스크립트는 set -e 하에서 종료 코드 1을 반환하는 경우입니다. 해당 코드는 "재부팅 필요"를 의미하므로, 스크립트를 종료시키는 대신 해당 코드에 따라 분기 처리를 하십시오.
• 라이브러리 업데이트 직후 needs-restarting -s가 아무것도 출력하지 않는다면, 보통 sudo 없이 실행했기 때문입니다. root 권한이 없으면 본인의 프로세스만 보이기 때문입니다.
• uname -r은 최신 설치된 커널보다 이전 버전을 보여주는데 needs-restarting -r은 재부팅이 필요 없다고 보고한다면, 보통 이전 커널로 부팅된 상태입니다. 이 검사는 설치 시간과 부팅 시간을 비교하는데, 둘 다 이미 과거의 시점이기 때문입니다. grubby --default-kernel를 확인하십시오. Rocky 또는 Alma 9에서는 두 번째 원인이 있습니다. 업데이트가 kernel 패키지 없이 kernel-core을 변경했는데, 9 빌드는 이를 감시하지 않으므로 재부팅이 여전히 대기 중인 상태입니다.
• needs-restarting --exclude-services가 인식할 수 없는 인자 오류로 실패한다면, 해당 옵션이 없는 9 빌드를 사용 중인 것입니다. 일반 sudo needs-restarting을 사용하십시오.
• 서비스를 재시작한 지 몇 분 후 다음 실행 시 다시 나타나는 서비스는 보통 다른 무언가에 의해 재시작되고 있거나, 유닛이 정상적으로 복구되지 못한 경우입니다. 해당 유닛을 두 번째로 재시작하기 전에 systemctl status를 읽어보십시오.

FAQ

Rocky Linux에서 dnf update는 서비스를 재시작합니까?

원칙적으로는 그렇지 않습니다. 트랜잭션은 파일을 기록하고 종료됩니다. 일부 패키지는 업그레이드 시 자체 서비스를 재시작하는 RPM 스크립틀릿을 포함하고 있으므로, 시스템 전체의 보장이라기보다는 패키지별 동작에 가깝습니다. sudo needs-restarting -s를 기준으로 삼으십시오. 이 명령은 서비스가 시작된 이후 파일이나 의존성 파일이 변경된 서비스를 나열하며, 스크립틀릿의 동작과 관계없이 결과를 보여줍니다.

최신 커널을 설치했는데 왜 needs-restarting -r은 재부팅이 필요 없다고 합니까?

이 명령은 핵심 패키지 목록의 RPM 설치 시간과 시스템 부팅 시간을 비교하기 때문입니다. 실행 중인 커널 버전과 설치된 최신 커널 버전을 직접 비교하지 않습니다. 커널을 설치하고 재부팅했으나 부트로더 기본값이 이전 커널을 가리키고 있어 구버전으로 부팅된 경우, 설치 시간이 부팅 시간보다 이전이므로 검사 결과는 아무것도 출력하지 않습니다. Rocky 및 Alma 9에서는 kernel 패키지 없이 수행된 kernel-core 업데이트를 놓칠 수 있는데, 이는 kernel-core이 9 버전 빌드 목록에 포함되어 있지 않기 때문입니다. 실제 상태를 확인하려면 uname -r, rpm -q --last kernel, sudo grubby --default-kernel을 실행하십시오.

Rocky와 Alma에서 재부팅 알림을 유발하는 패키지는 무엇입니까?

플러그인 내부에 하드코딩된 목록이 있습니다. Rocky 및 Alma 10에서는 kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl이 포함됩니다. 9 버전에서는 kernel-core를 제외한 동일한 목록을 사용합니다. 이 목록은 확장할 수 있습니다. /etc/dnf/plugins/needs-restarting.d/ 디렉터리에 패키지 이름을 한 줄에 하나씩 적은 .conf 파일을 생성하면, 해당 패키지도 재부팅 판단 기준에 포함됩니다.

dnf-automatic이 스스로 서버를 재부팅할 수 있습니까?

네. /etc/dnf/automatic.conf의 [commands] 섹션에서 reboot = when-needed를 설정하면 적용된 트랜잭션이 재부팅을 요구할 때만 재부팅을 수행합니다. when-changed은 패키지 변경 후 항상 재부팅하며, never가 기본값입니다. reboot_command은 재부팅 방식을 제어하며, 기본값은 로그인한 사용자에게 5분 전 경고를 보내는 것입니다. 부팅 문제를 직접 해결할 수 있는 시스템에서만 이 기능을 활성화하십시오. 콘솔 접근이 불가능한 VPS에서 무인 재부팅이 발생하면 심각한 장애 상황이 될 수 있습니다.

needs-restarting은 컨테이너 내부의 프로세스를 감지합니까?

유용하지 않습니다. 이 명령은 실행 중인 프로세스를 호스트의 RPM 데이터베이스와 대조하는데, 컨테이너 이미지 내부의 패키지는 해당 데이터베이스에 존재하지 않으므로 이미지에 포함된 구버전 라이브러리는 나타나지 않습니다. 이미지를 다시 빌드하고 배포하십시오. 호스트 측면은 여전히 중요합니다. 컨테이너 런타임과 공유 커널은 호스트 패키지에 해당하므로 이들은 정상적으로 감지됩니다.