재부팅으로 인해 비정상적인 종료가 발생할 수 있는 원인은 무엇입니까?

Question

가독성을 높이기 위해 로그 줄이 래핑됩니다.

Jul 15 03:08:04 xxxxxxxxxx python: ansible-ansible.legacy.command Invoked with creates=None \
    executable=None _uses_shell=False strip_empty_ends=True _raw_params=/sbin/shutdown -r +1 \
    removes=None argv=None warn=False chdir=None stdin_add_newline=True stdin=None

shutdown -r +1누군가 또는 무언가가 Ansible을 사용하여 전화를 걸고 있는 것 같습니다 .

닫기 전 마지막 메시지는 다음과 같습니다.

Jul 15 03:09:04 xxxxxxxxxx systemd: Stopping LSB: Starts and stops IHS...
Jul 15 03:09:04 xxxxxxxxxx systemd: Stopping ACPI Event Daemon...
Jul 15 03:09:04 xxxxxxxxxx systemd: Stopped Resets System Activity Logs.
Jul 15 03:09:04 xxxxxxxxxx systemd: Stopping Zabbix Agent...
Jul 15 03:09:04 xxxxxxxxxx systemd: Stopping System Logging Service...

...이는 통제된 폐쇄로 인해 많은 진전이 이루어졌음을 의미합니다. syslog 서비스가 중지된 후에는 다시 시작될 때까지 더 이상 로그 항목이 없습니다 /var/log/messages. 영구 시스템 로깅을 활성화하면(디렉토리를 생성하여 /var/log/journal) 를 사용하여 종료하기 전에 더 많은 항목을 볼 수 있습니다 journalctl.

작업을 종료하기 전에 Ansible 작업이 실행 중인 것 같습니다 yum.

Jul 15 03:01:53 xxxxxxxxxx python: ansible-ansible.legacy.yum Invoked with lock_timeout=30 \
    update_cache=False conf_file=None exclude=[] allow_downgrade=False disable_gpg_check=False \
    disable_excludes=None use_backend=auto state=latest disablerepo=[] skip_broken=False \
    releasever=None autoremove=False download_dir=None enable_plugin=[] installroot=/ \
    install_weak_deps=True name=['*'] download_only=False bugfix=False list=None \
    install_repoquery=True update_only=False disable_plugin=[] enablerepo=[] security=True \
    validate_certs=True

yum이것이 커널 업데이트를 가져왔는지 확인하고, 그렇다면 initramfs 생성이 성공했는지 확인하는 것이 좋습니다 . 나는 이전에 RHEL 7.x에서 initramfs 생성이 실패한 상황을 본 적이 있다고 생각합니다. 예를 들어 yum패키지 캐시로 인해 파일 시스템이 꽉 차서 새 커널로 부팅하지 못하기 때문입니다. 때로는 파일 시스템을 루트로 마운트하기 전에도 실패합니다. 읽기/쓰기 모드에 있었습니다. 이는 분명히 이 부팅 시도에 대해 로그가 기록되지 않음을 의미합니다.

이는 VMware 가상 머신이므로 하이퍼바이저(및/또는 가능한 경우 vSphere 관리) 로그는 시스템 충돌 후 발생한 상황을 자세히 설명할 수 있습니다. 아마도 예정된 하이퍼바이저 서비스 중단이 있었고 VMware 관리자는 중단 부분까지 VM 시작을 방지했습니다. 완료됐나요?

또한 시스템이 온라인 상태가 되고 NTP 시간 동기화가 활성화될 때까지 재부팅 직후 기록된 시간 값을 맹목적으로 신뢰하지 않습니다. 혼합된 Windows/Linux VMware 환경에서는 VMware 시간 동기화를 비활성화하는 것을 잊을 수 있습니다. 환경이 Windows 가상 머신에 의해 지배되는 경우 VMware 호스트는 현지 시간으로 시스템 시계를 실행할 수 있으며 가상 머신 가상 시계는 부팅 시 기본적으로 해당 시간으로 설정됩니다.

이 경우 NTP 동기화 서비스가 시작되면 사이트의 현재 UTC/DST 오프셋과 대략 동일할 수 있는 시작 시 시간 점프가 표시됩니다. 나중에 부팅 후 타임스탬프가 7월 15일 08:3x:xx에서 대략 7월 15일 03:xx:xx로 점프하는 경우 VM은 가상 하드웨어 시계가 UTC이고 Windows A를 실행하고 있다고 (잘못) 가정하도록 구성된 것입니다. UTC+4(+DST, 북반구) 또는 UTC+5(DST 없음) 시간대에 위치한 VMware 중심 환경입니다.

2022년 7월 15일 08:38:48.151:6의 시스템 시작과 2022년 7월 18일 06:17:40.034:6의 다음 시작 사이에 비정상적인 종료가 발생했습니다. 귀하의 /var/log/messages발췌 내용은 해당 시간 간격을 다루지 않습니다.

비정상적인 종료로 인해 발생한 상황을 파악하려면 다음을 찾아야 합니다.2022년 7월 18일 06:17:40 이전의 마지막 로그 항목.

만약 있다면/var/log/messages7월 15일 08:38:30 이후에는 더 이상 로그인이 불가능합니다., 그런 다음 가상 머신이 해킹되어 (서숙하지 않게) 루트킷되었을 가능성을 고려합니다. 이것이 사실로 밝혀지면 종료 시 충돌이 발생하는 것은 가상 머신의 루트킷 및/또는 기타 맬웨어의 부작용일 수 있지만 현재로서는 걱정할 필요가 가장 적을 것입니다.

Answer 1