Read the record before you trust your own memory

What happened and why it matters

I was certain one of my computers was restarting itself at around eight in the morning, a couple of times a week, when nobody was even using it. I had said so out loud more than once. I had a theory about why. I opened the record of past restarts to confirm it, which felt like a formality.

In forty five days, that machine had started up at eight o'clock exactly once.

The restarts were not clustered at eight at all. They were at ten and eleven. My story was not slightly off. It was wrong, and I had been reasoning from it for weeks. Every plan I had sketched out to catch the eight o'clock restart would have sat there patiently watching an hour when nothing ever happened.

Two different problems wearing the same disguise

The record did not hand me one tidy answer either, and this is the part worth staying for. There were two separate causes wearing the same costume, and either one on its own would have looked like the machine restarts sometimes.

The first was genuine crashes. Six of them across three weeks, all with an identical fingerprint, all pointing at the same piece of graphics software. The machine was set to restart itself immediately after a crash, which is a sensible default and also the exact reason nobody ever saw one. It would fall over and be back before anyone looked, leaving no trace except a computer that was mysteriously freshly started. The helpful behaviour is what made the failure invisible.

The second was the system installing its updates. That one was not a fault at all. It was the machine doing precisely what it had been told to do, on a schedule I set myself and then forgot. Updates were instructed to keep out of the hours I was likely to be working, so they waited politely all night and then went ahead the moment those protected hours ended in the morning. Not random. Not broken. A monthly appointment I had made and forgotten about.

Two causes, one symptom. Averaging them together in my head produced the fiction of a twice weekly eight o'clock restart that existed nowhere except in my memory.

The fix, and the part I cannot yet promise

The fix for the annoying half was small. There is a setting that tells the system to carry on downloading and installing updates exactly as before, but to stop restarting on its own and wait for a person instead. The updates keep flowing, which genuinely matters, because the popular alternative is switching updates off altogether. That trades a small annoyance for a real security problem, and it is a bad trade.

Here is the catch I am not going to paper over. That setting belongs to an older generation of the update system, and the restarts I actually caught in the record were being driven by newer machinery. The setting is in place. Whether it will actually hold is not proven, and I cannot prove it today.

The real test is the next update cycle, and I know the date that will happen. If the machine restarts itself that morning anyway, the setting did not take, and the next thing to change is the protected hours themselves.

The lesson: go and read the evidence before you act on the story, especially when the story is your own. Then check whether the pattern you found is one thing, or two things standing very close together.

How to do it yourself

Steps one to four only read information and change nothing, so they are safe to run purely out of curiosity. Only the last two change a setting. If your machine is not restarting unexpectedly, the first half is still a good way to learn what your computer has actually been doing.

1. Get the real restart history

# Linux: every start up the system remembers
journalctl --list-boots

# count them by hour, which is what actually answers the question
journalctl --list-boots -o short-iso \
  | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn

# Windows: event 6005 marks a start up
Get-WinEvent -FilterHashtable @{LogName='System'; Id=6005} |
  Group-Object { $_.TimeCreated.Hour } | Sort-Object Name |
  Format-Table Name, Count

2. Tell crashes apart from planned restarts

# Linux: did it shut down cleanly, or just stop?
journalctl -b -1 -p err --no-pager | tail -20
last -x reboot shutdown | head

# Windows: event 1074 names WHICH program asked, and why
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} |
  Select-Object TimeCreated, Message -First 10

3. Read the crash record, it usually names the culprit

# Windows
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} |
  Select-Object TimeCreated, Message -First 10

# Linux: the last words of the previous session
journalctl -b -1 -k --no-pager | tail -40

4. Find the protected hours that decide when restarts land

# Windows: the hours updates are told NOT to restart in
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings' |
  Select-Object ActiveHoursStart, ActiveHoursEnd

# Linux: the scheduled update job, and when it last ran
systemctl list-timers --all | grep -i -E 'upgrade|update'
grep -r 'Automatic-Reboot' /etc/apt/apt.conf.d/ 2>/dev/null

5. Keep the updates, remove the surprise

# Windows: install as normal, but do not restart while somebody is signed in
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" ^
  /v NoAutoRebootWithLoggedOnUsers /t REG_DWORD /d 1 /f
gpupdate /force

# Linux: in the file /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "false";

6. Check it held, and know when you will really find out

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" \
  /v NoAutoRebootWithLoggedOnUsers

# and confirm updates are still flowing, which is the whole point
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

Then put a note in your calendar for the next update cycle, because that is the only thing that actually proves this worked. Until that date passes, be honest with yourself that you have a hypothesis rather than a fix.

Related reading: before you fix the machine, prove the gauge is not the broken part is the same instinct aimed at your warnings, and measure before you delete is the same instinct aimed at your hard drive.