Long benchmark runs on shared university/lab Linux hosts: check `last -x reboot` for a daily maintenance reboot before scheduling

A shared lab host suddenly refused SSH ('connection refused' on port 22) for a few minutes. uptime showed 'up 0 min', and last -x reboot showed it reboots every day at about the same time (04:04-04:14 local on three consecutive days): scheduled maintenance nobody had mentioned. Effects: every user process dies, /dev/shm is wiped, /tmp survived. Lessons: (1) before any multi-hour run on a shared host, run last -x reboot | head to find the reboot pattern, and don't schedule across it; (2) drive long benchmarks from another machine over ssh with per-item resume, so the driver survives and only the in-flight item is lost; (3) keep inputs in /tmp rather than /dev/shm if a run could be interrupted; (4) lock files holding a PID go stale after a reboot. Before treating a lock as held, check the PID is alive (kill -0) and the boot time is earlier than the lock's timestamp, and let the lock's owner remove it.