rsyslog 및 상호 TLS를 사용한 안전한 SLES Syslog 포워딩
SLES 시스템 로그를 인증된 TLS를 통해 원격 rsyslog 수집기로 전송하고, 인증서 확인, 장애 버퍼링 및 전송 테스트를 수행합니다.
SLES 업그레이드 중에 "메모리를 할당할 수 없습니다"라는 오류 메시지가 표시되면 먼저 커널에 메모리 부족 이벤트가 기록되었는지, RAM이나 스왑 공간이 부족해졌는지 확인하십시오. 메모리 부족을 확인한 후에만 필수적이지 않은 워크로드를 일시 중지하거나 가상 머신에 할당된 메모리를 늘리십시오. 그런 다음 Zypper와 RPM 프로세스가 더 이상 활성화되어 있지 않은지 확인한 후 원래 업그레이드 절차를 재개하십시오.
가상 사례: 관리자가 대규모 배치 작업이 실행 중인 SLES 15 가상 머신에서 예약된 패키지 업데이트를 시작한다고 가정해 보겠습니다. 이때 Zypper가 메모리 할당 오류와 함께 중지됩니다. 아래 예시는 설명을 위한 것이며 실제 사고 또는 테스트 보고서가 아닙니다. 해결책을 선택하기 전에 해당 명령어를 사용하여 실제 호스트에서 증거를 수집하십시오.

SSH 세션에 오류가 표시되었다고 해서 재부팅하거나, 패키지 프로세스를 종료하거나, 두 번째 업그레이드 명령을 실행하지 마십시오. 두 번째 세션에서 다시 연결하여 활성 Zypper 또는 RPM 프로세스가 있는지 확인하십시오.
pgrep -a 'zypper|rpm'
패키지 프로세스가 아직 실행 중인 경우, 잠시 기다렸다가 출력 또는 로그를 확인하십시오. 패키지 작업이 진행 중일 때는 Zypper 잠금 파일을 삭제하지 마십시오. 실행 중인 프로세스가 없는 경우, 정확한 오류 메시지와 발생 시간을 기록해 두십시오. 해당 타임스탬프는 커널 로그와 패키지 로그를 연관 짓는 데 도움이 됩니다.
현재 RAM 및 스왑 스냅샷을 수집합니다.
free -h
swapon --show
vmstat 1 5

`swap` 파일 에서 표시된 양뿐만 아니라 열을 free -h확인하세요 . Linux는 캐시용으로 RAM도 사용합니다. `swap` 파일은 스왑이 존재하는지, 그리고 얼마나 사용되는지를 보고합니다. `swap` 파일에서 최근 행에 0이 아닌 값이 반복적으로 나타나면 활성 스왑이 발생하고 있음을 나타냅니다. 첫 번째 행은 부팅 이후 평균값이므로 이후 행에 집중해야 합니다.availablefreeswapon --showvmstatsiso
그런 다음 오류 발생 지점 주변에서 커널 메모리 부족(OOM)으로 인한 프로세스 종료를 찾아보고 Zypper 로그를 읽어보세요.
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
sudo tail -n 80 /var/log/zypper.log
RPM, Zypper 또는 다른 프로세스 이름을 언급하는 OOM-kill 기록은 실제 메모리 부족 문제를 진단하는 데 도움이 됩니다. 단순히 "사용 가능한" RAM이 부족하다는 것만으로는 정확한 원인을 파악할 수 없습니다. 캐시가 회수될 수도 있고, 프로세스 또는 서비스의 메모리 제한으로 인해 메시지가 발생할 수도 있기 때문입니다. 커널 OOM 항목이 나타나지 않으면 호스트 메모리를 추가하기 전에 실패한 명령의 제한 사항과 systemd 또는 컨테이너의 메모리 제한을 확인하십시오. "메모리를 할당할 수 없습니다"라는 문구만으로는 정확한 원인을 파악할 수 없습니다.
가상 VM으로 돌아가십시오. 배치 작업이 메모리를 과도하게 사용하고 시스템에서 지속적인 스왑 활동이 발생하거나 커널 OOM(메모리 부족) 오류가 발생하는 경우, 해당 애플리케이션에서 지원하는 일시 중지 또는 중지 절차를 사용하십시오. 운영자가 지정한 종료 절차 없이 데이터베이스, SAP 워크로드 또는 기타 상태 저장 서비스를 종료하지 마십시오. 워크로드를 일시 중지한 후 RAM과 스왑 사용량을 다시 확인하십시오.

정상 유지 관리 중에 게스트 운영 체제의 메모리가 부족한 경우, 지원되는 하이퍼바이저 또는 클라우드 제어 평면을 통해 할당된 RAM을 늘린 다음 운영 체제에서 새 용량을 인식하는지 확인하십시오. 스왑을 추가하면 일시적인 여유 공간을 확보할 수 있지만 RAM보다 속도가 느리고 지속적인 메모리 부족 문제를 해결하지 못합니다. SLES의 스토리지 레이아웃은 중요합니다. 예를 들어, SUSE는 Btrfs 파일 시스템의 스왑 파일에 대한 특정 제약 조건을 문서화하고 있습니다. 파일 시스템, 스냅샷 및 플랫폼 요구 사항을 확인하기 전에는 업그레이드 중에 스왑을 생성하거나 크기를 조정하지 마십시오.
OOM(메모리 부족) 기록이 없는 경우, 오류가 발생하는 프로세스에 적용되는 제한 사항을 조사하십시오. SLES 15에서는 systemd로 관리되는 워크로드의 구성된 메모리 제한을 검사하고, 샘플 단위 이름은 영향을 받는 서비스 이름으로 바꾸십시오.
sudo systemctl show example-batch.service -p MemoryMax해당 값을 사용 가능한 메모리와 비교하십시오. cgroup 제한은 VM의 RAM을 늘려도 해결되지 않으며, 제한 자체도 적절하게 높여야 합니다. 이전 서비스 팩의 경우 해당 릴리스의 systemd 설명서를 참조하여 속성 이름을 확인하십시오.
패키지 프로세스가 종료되면 /var/log/zypper.log마지막으로 완료된 작업과 실패한 패키지를 확인하십시오. RPM 또는 Zypper에서 트랜잭션이 완료되지 않았다고 보고하는 경우, 다시 시도하기 전에 해당 오류에 대한 SUSE의 복구 지침을 따르십시오. 패키지 데이터베이스 파일이나 잠금을 수동으로 제거하지 마십시오.
처음에 시작했던 업그레이드 경로를 그대로 사용하십시오. 정기 패키지 유지 관리와 서비스 팩 마이그레이션은 서로 다른 작업입니다. SUSE 문서에서는 zypper patch적용 가능한 릴리스 패치 설치 방법을 안내하고 있으며, 서비스 팩 및 주요 릴리스 업그레이드는 각각 지원되는 경로와 준비 과정이 있습니다. 단순히 메모리 부족 문제를 해결하기 위해 다른 방법으로 전환하지 마십시오 zypper dup. 정기 패치 실행의 경우, 먼저 해당 트랜잭션을 검토하십시오.
sudo zypper patch --dry-run

모의 실행 결과가 합리적이고 메모리가 안정적이라면 유지 관리 시간을 예약하고 원래 작업에 맞는 명령어를 실행하세요. SSH 세션을 유지하고 프로세스를 모니터링한 후 결과를 확인하십시오.
sudo tail -n 80 /var/log/zypper.log
sudo journalctl -k -b --since "30 minutes ago" | grep -Ei 'oom|out of memory|killed process'
성공적인 복구란 의도한 패키지 또는 마이그레이션이 완료되고, Zypper가 정상적으로 종료되었으며, 실행 중에 새로운 OOM(메모리 부족) 이벤트가 발생하지 않았음을 의미합니다. 시스템이 부팅 가능하지만 SLES 서비스 팩 마이그레이션 자체를 되돌려야 하는 경우, SUSE에서 제공하는 Snapper 롤백 기능은 지원되는 Btrfs 루트와 구성된 스냅샷을 포함한 요구 사항이 충족될 때만 적용됩니다. 롤백을 패키지 패치 실패에 대한 일반적인 대응책으로 간주해서는 안 됩니다.
메모리 부족 현상이 해소된 후에도 오류가 반복되거나, 패키지 프로세스가 여전히 멈춰 있거나, RPM 데이터베이스가 손상되었다고 보고되는 경우, 재시도를 중단하십시오. Zypper 로그, 커널 저널, 제품 및 서비스 팩 수준, 그리고 사용한 정확한 명령어를 보관하십시오. SUSE는 supportconfig이러한 정보를 수집하여 지원 사례를 지원할 수 있습니다. 여기에 제시된 단계는 메모리 부족 현상과 다른 할당 오류를 구분하는 데 도움이 되지만, 전체 로그와 시스템 구성 정보 없이는 특정 제품의 결함을 확인할 수는 없습니다.
최신 SLES 15 SP7에 대한 자세한 내용은 SUSE의 시스템 모니터링 유틸리티 , 로그 파일 참조 , Zypper 관리 지침 , 스왑 및 Btrfs 요구 사항 , 온라인 업그레이드 및 롤백 지침을 참조하십시오 . 명령 및 복구 경로는 SLES 서비스 팩, 아키텍처, 파일 시스템, 그리고 패치 작업인지 릴리스 마이그레이션 작업인지에 따라 다를 수 있습니다.
SLES 시스템 로그를 인증된 TLS를 통해 원격 rsyslog 수집기로 전송하고, 인증서 확인, 장애 버퍼링 및 전송 테스트를 수행합니다.
RAM, 스왑, 커널 및 Zypper 로그를 사용하여 실제 메모리 부족 현상을 파악하고, 패키지 상태를 보호하고, 보다 안전한 SLES 업그레이드 재시도 방법을 선택하십시오.
SSH를 통한 Debian의 무인 보안 업데이트를 활성화하고, 기본 패키지 소스를 유지하며, systemd 및 APT 로그를 통해 예약된 실행을 확인하십시오.
메일 전송 옵션을 비교하고, Ubuntu에서 smartd를 구성하고, 디스크 상태 경고가 받은 편지함에 제대로 도착하는지 확인하세요.
debian 12에서 DNS 조회를 복원하려면 systemd-resolved를 확인하고, 필요한 경우 resolv.conf를 복구하고, 상위 DNS 및 애플리케이션 이름 확인을 검증하십시오.
Ubuntu에서 모니터 또는 TV를 오디오 출력 장치로 인식하도록 하려면, 소리 설정에서 해당 장치를 선택하고, HDMI가 없는 경우 연결 또는 PipeWire 장치 목록을 확인하십시오.
보안을 비활성화하지 않고도 오류가 발생한 소스를 식별하고, 검증된 키를 갱신하고, 결과를 확인하여 Ubuntu APT 서명 경고를 안전하게 해결할 수 있습니다.
균형 잡힌 3상 공식을 배우고, 선간 전압, 전류, kW, kVA 및 역률을 단계별로 변환하는 방법을 예제와 함께 확인하고 점검 범위를 살펴보세요.
CPUQuota 및 MemoryMax를 사용하여 systemd 범위 내에서 워크로드를 실행한 다음 cgroup v2를 통해 제한 사항을 확인합니다.
Ubuntu 24.04에서 dnscrypt-proxy를 Pi-hole의 로컬 DoH 브리지로 설정하고, localhost 전용 리스너, 리졸버 선택, DNS 전환 전 검사 기능을 추가합니다.