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 플러그인입니다. 이 플러그인은 대부분의 Rocky 및 Alma 설치 환경에 이미 포함된 dnf-plugins-core을 통해 제공됩니다. /usr/bin/needs-restarting 명령어는 dnf-utils에 포함된 작은 래퍼(wrapper)입니다.

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

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

needs-restarting -r
dnf needs-restarting -r

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

Rocky Linux 10 및 AlmaLinux 10 계열에서 dnf은 DNF 5이며, needs-restarting은 dnf5-plugins 패키지에 포함된 자체 명령어 중 하나입니다. 해당 환경에서는 옵션 없이 dnf needs-restarting을 실행하면 재부팅 필요 여부를 즉시 확인할 수 있습니다. -r도 여전히 허용되지만, 매뉴얼에 따르면 아무런 기능이 없으며 기존 DNF 4 스크립트와의 호환성을 위해서만 존재합니다.

Tier 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로 감싸야 합니다.

재부팅 알림을 유발하는 패키지들은 플러그인 내부에 하드코딩된 짧은 목록에 포함되어 있습니다. 현재 버전에서는 kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl이 포함됩니다. 이전 플러그인 빌드에는 더 짧은 목록이 포함되어 있을 수 있으므로, 가정하지 말고 직접 확인하십시오.

각 항목이 목록에 있는 이유는 명확합니다. 새로운 kernel 패키지는 /boot 및 /lib/modules에 파일만 기록하며, 실행 중인 커널은 스스로 교체될 수 없으므로 재부팅 전까지는 아무것도 변경되지 않습니다. 시스템의 모든 프로세스는 glibc를 링크하고 있으며, 이는 "영향받는 서비스 재시작"이 곧 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 설치 시간을 읽고 시스템 부팅 시간과 비교합니다. 핵심 패키지가 마지막 부팅 이후에 설치되었다면 "reboot required"라는 결과가 나옵니다. 부팅 시간은 사용 가능한 경우 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은 다음 부팅 시 부트로더가 선택할 커널을 출력합니다. 이 세 가지 결과가 일치하지 않는다면, 콘솔로 접근할 수 없는 장비를 재부팅하기 전에 부팅 기본값을 수정하십시오.

Tier 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 작업 및 수동으로 시작한 프로세스만 남습니다. 이러한 프로세스는 스스로 재시작되지 않습니다.

목록에 있는 서비스가 재부팅이 필요한 패키지인 경우, 도구는 그 위에 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이 존재합니다.

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는 dnf-utils이 설치되지 않았음을 의미합니다. 해당 패키지를 설치하거나, dnf-plugins-core이 존재하는 즉시 작동하는 dnf needs-restarting을 대신 호출하십시오.
• 재부팅 확인 단계에서 오류 메시지 없이 멈추는 스크립트는 set -e 하에서 종료 코드 1을 반환하는 경우입니다. 해당 코드는 "재부팅 필요"를 의미하므로, 스크립트를 종료시키는 대신 해당 코드에 따라 분기 처리를 수행하십시오.
• 라이브러리 업데이트 직후 needs-restarting -s이 아무것도 출력하지 않는다면, 대개 sudo 없이 실행했기 때문입니다. root 권한이 없으면 본인의 프로세스만 보이기 때문입니다.
• needs-restarting -r는 재부팅이 필요 없다고 보고하지만 uname -r은 이전 버전을 표시한다면, 이는 구버전 커널로 부팅된 상태입니다. 이 검사는 설치 시간과 부팅 시간을 비교하는데, 두 시점 모두 현재보다 과거이기 때문입니다. grubby --default-kernel를 확인하십시오.
• 재시작한 지 몇 분 지나지 않아 다음 실행 시 다시 나타나는 서비스는, 대개 다른 무언가에 의해 재시작되고 있거나 해당 유닛이 정상적으로 복구되지 못한 경우입니다. 두 번째로 재시작하기 전에 해당 유닛의 systemctl status를 읽어보십시오.

FAQ

Rocky Linux에서 dnf update를 실행하면 서비스가 재시작됩니까?

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

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

이 명령은 핵심 패키지 목록의 RPM 설치 시간과 시스템 부팅 시간을 비교하기 때문입니다. 실행 중인 커널 버전과 설치된 최신 커널 버전을 직접 비교하지 않습니다. 커널을 설치한 뒤 재부팅했더라도 부트 로더 설정이 이전 커널을 가리키고 있다면, 설치 시간이 부팅 시간보다 이전으로 간주되어 아무런 경고를 출력하지 않습니다. 실제 상태를 확인하려면 uname -r, rpm -q --last kernel, sudo grubby --default-kernel를 실행하십시오.

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

플러그인 내부에 하드코딩된 목록이 있으며, 현재 버전에서는 kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon, microcode_ctl가 포함되어 있습니다. 이 목록은 확장 가능합니다. /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 데이터베이스와 대조하는데, 컨테이너 이미지 내부의 패키지는 해당 데이터베이스에 존재하지 않기 때문입니다. 따라서 이미지에 포함된 구버전 라이브러리는 감지되지 않습니다. 이미지를 다시 빌드하고 배포해야 합니다. 다만 호스트 측면은 여전히 중요합니다. 컨테이너 런타임과 공유 커널은 호스트 패키지에 해당하므로, 이들은 정상적으로 감지됩니다.