[GH-ISSUE #95] [QUESTION] VM rebooted during apt update #48

Closed
opened 2026-03-03 13:58:41 +03:00 by kerem · 4 comments
Owner

Originally created by @frederikbosch on GitHub (Jul 26, 2021).
Original GitHub issue: https://github.com/konstruktoid/hardening/issues/95

Originally assigned to: @konstruktoid on GitHub.

I have a hardened 18.04 machine, made more than a year ago @ commit bd559d812c. Last week there were two security updates for systemd, and this caused my VMs to be rebooted. I believe it was the udev/libudev update that caused the reboot. But by what setting is getting triggered? My guess would be that is a auditd setting. Do you have any idea?

Originally created by @frederikbosch on GitHub (Jul 26, 2021). Original GitHub issue: https://github.com/konstruktoid/hardening/issues/95 Originally assigned to: @konstruktoid on GitHub. I have a hardened 18.04 machine, made more than a year ago @ commit bd559d812c51514023b1f36f400140d2c301e36e. Last week there were [two security updates for systemd](http://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_237-3ubuntu10.50/changelog), and this caused my VMs to be rebooted. I believe it was the udev/libudev update that caused the reboot. But by what setting is getting triggered? My guess would be that is a auditd setting. Do you have any idea?
kerem 2026-03-03 13:58:41 +03:00
  • closed this issue
  • added the
    Stale
    label
Author
Owner

@konstruktoid commented on GitHub (Jul 26, 2021):

Hi @frederikbosch
Did the host reboot or halt? It could be the audit configuration that triggers a halt when then disk gets full.

<!-- gh-comment-id:886808904 --> @konstruktoid commented on GitHub (Jul 26, 2021): Hi @frederikbosch Did the host reboot or halt? It could be the audit configuration that triggers a halt when then disk gets full.
Author
Owner

@frederikbosch commented on GitHub (Jul 26, 2021):

Hi @konstruktoid. Nope, it was the update of either udev or libudev that triggered the reboot. So I found out that udev is the device manager for the Linux kernel. Maybe updating the package causes the devices to be reloaded which is not allowed by the audit configuration?

<!-- gh-comment-id:886815027 --> @frederikbosch commented on GitHub (Jul 26, 2021): Hi @konstruktoid. Nope, it was the update of either udev or libudev that triggered the reboot. So I found out that udev is the device manager for the Linux kernel. Maybe updating the package causes the devices to be reloaded which is not allowed by the audit configuration?
Author
Owner

@konstruktoid commented on GitHub (Jul 26, 2021):

The audit system could cause a halt if the log partition gets full.
Otherwise I would check the needrestart configuration, but that shouldn't cause a reboot.

Any pre-reboot logs or dmesg messages?

<!-- gh-comment-id:886888657 --> @konstruktoid commented on GitHub (Jul 26, 2021): The audit system could cause a halt if the log partition gets full. Otherwise I would check the `needrestart` configuration, but that shouldn't cause a reboot. Any pre-reboot logs or dmesg messages?
Author
Owner

@github-actions[bot] commented on GitHub (Aug 26, 2021):

This issue is stale because it has been open 30 days with no activity, without any activity it will be closed in 5 days.

<!-- gh-comment-id:905970796 --> @github-actions[bot] commented on GitHub (Aug 26, 2021): This issue is stale because it has been open 30 days with no activity, without any activity it will be closed in 5 days.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hardening#48
No description provided.