Linux VM shutsdown automatically

Faris Ali

If your Linux VM is shutting down automatically every 15–20 minutes and no auto‑shutdown schedule is configured, this behavior is typically caused by platform recovery actions (host/infrastructure issues) or guest OS‑initiated shutdowns. Please follow the structured troubleshooting steps below to identify the root cause.

Step 1: Check Azure Activity Log (Most Important)

This confirms whether the shutdown is customer‑initiated (Portal/CLI/Automation/Policy) or Azure platform‑initiated.

Azure Portal VM > Activity log

Filter for:

1. Stop Virtual Machine
2. Deallocate Virtual Machine
3. Check Initiated by field (User / Managed Identity / Automation / Azure platform)

az monitor activity-log list \
  --resource-id <VM_RESOURCE_ID> \
  --status Succeeded \
  --max-events 50 \
  --query "[?operationName.value=='Microsoft.Compute/virtualMachines/deallocate/action']"

Ref documentation - https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log?tabs=log-analytics

Step 2 : Azure provides a supported diagnostic flow that can surface Root Cause Analysis (RCA).

Path

1. VM > Help + troubleshooting
2. Diagnose and solve problems
3. Common problems > VM restarted or stopped unexpectedly
4. Select “My resource has been stopped unexpectedly”

Note: If the issue is platform‑related, Resource Health may publish RCA details up to 72 hours after the event.

For unexpected VM restarts/stops: https://learn.microsoft.com/troubleshoot/azure/virtual-machines/windows/unexpected-vm-reboot-root-cause-analysis

Step 3 : Check Azure Resource Health

This confirms host‑level faults, service healing, or unexpected downtime.

VM > Resource health

Review past health events around shutdown times

Understand VM reboots & service healing: https://learn.microsoft.com/azure/virtual-machines/understand-vm-reboots

Step 4 : Check Linux OS‑Level Logs

If Azure logs do not show a deallocate event, the shutdown may be guest OS‑initiated (kernel panic, OOM kill, crash).

Run inside the VM (or via Serial Console if SSH drops):

# Check previous shutdown reasons
sudo journalctl -b -1 -e
# Look for shutdown / crash events
sudo journalctl | grep -i -E "shutdown|panic|oom|error|critical"
# Check kernel messages
sudo dmesg | tail -100

Step 5: Check Azure Linux Agent Health

# Check agent status
systemctl status walinuxagent || systemctl status waagent
# Update agent (Ubuntu/Debian)
sudo apt update
sudo apt install walinuxagent -y
sudo systemctl restart walinuxagent
# Validate version
waagent --version

Troubleshoot the Azure Linux Agent - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/linux-azure-guest-agent

Update Linux Agent: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/update-linux-agent?tabs=ubuntu

Step 6: Redeploy the VM (If Host Issue Suspected)

If shutdowns continue and Activity Log / Resource Health indicates infrastructure instability, Redeploy moves the VM to a new Azure host without changing disks or configuration.

From Azure Portal - VM > Help + troubleshooting

Redeploy + reapply and then Redeploy

az vm redeploy \
  --resource-group <RG_NAME> \
  --name <VM_NAME>

Note: Temporary disk data will be lost. OS and data disks remain intact.

Redeploy Windows virtual machine to new Azure node - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/redeploy-to-new-node-windows

Regards

Himanshu

The behavior matches a known scenario where a Linux VM shuts down because of audit daemon (auditd) configuration combined with a full or nearly full OS disk, especially the filesystem that holds /var/log/audit.

Use these steps to diagnose and remediate:

1. Check if auditd is forcing shutdown
   • Open the VM’s serial console in Azure and review the boot/console log.
   • If messages similar to Starting Security Auditing Service… appear followed quickly by an orderly shutdown ending with Power down or Power-off, auditd is likely triggering the shutdown when it can’t write to the audit log.
2. Verify disk usage on the audit log filesystem
   • Attach the OS disk to a recovery VM, or use az vm repair or single-user mode to access the filesystem.
   • Run df and confirm whether the disk/partition containing /var/log/audit is at or near 100% utilization.
3. Temporarily relax auditd shutdown behavior
   • Still from the recovery context (repair VM or single-user mode), open /etc/audit/auditd.conf.
   • Locate the following settings:

          admin_space_left_action = HALT
          disk_full_action = HALT
          disk_error_action = HALT
     

   • Change each HALT value to another valid action that does not shut down the system, such as SUSPEND, IGNORE, or SYSLOG, for example:

          admin_space_left_action = SUSPEND
          disk_full_action = SUSPEND
          disk_error_action = SUSPEND
     

   • Reattach the disk to the original VM (if using a recovery VM) and boot normally, or exit single-user mode to reboot.
4. Free disk space
   • Once the VM boots fully, use tools like df and du to identify large files and free space, especially on the filesystem containing /var/log/audit.
   • As a starting point, ensure roughly 10% free space on that filesystem.
5. Restore security posture
   • After resolving the space issue and confirming the VM remains stable, revert /etc/audit/auditd.conf to the original values if required by security policy and reboot.
6. Optional: Use Azure Linux Auto Repair (ALAR)
   • Instead of manual edits, the auditd action in Azure Linux Automatic Repair (ALAR) can automatically adjust auditd.conf by changing any HALT actions to SYSLOG and, in LVM environments with free space, attempt to extend the logical volume that holds the audit logs.
   • This action also backs up the original auditd.conf in /etc/audit so the configuration can be reviewed and restored after the VM is stable.

If the VM is still reported as unavailable for 15 minutes or more in Resource Health after these steps, also review Azure activity logs and the Diagnose and Solve blade on the VM to rule out platform maintenance, storage-related forced shutdowns, or other crash causes.

References:

• Troubleshoot Azure Linux virtual machine boot issues due to full OS disk
• Use Azure Linux Auto Repair (ALAR) to fix a Linux VM
• Azure virtual machine (VM) is unavailable for 15 minutes
• Understand a system reboot for Azure VM