Load-Shedding-Aware Server Shutdown and Restart Orchestrator for Small Offices
Build a service that watches a small office's UPS or solar inverter battery during power cuts and shuts down servers, virtual machines and containers in the right order before the battery runs out, then brings everything back and checks it is healthy when power returns. Offices in Pakistan running a local server through daily load shedding lose data and hours to dirty shutdowns. This makes each outage boring.
Beginner
Achievable by one student in a semester with familiar tools.1 semester · 2 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- A battery reader using NUT for UPS units and at least one inverter readout (USB, serial or Wi-Fi API)
- A runtime estimator that predicts minutes left from load and battery history, not just percentage
- A dependency file describing services and the order they must stop and start (apps before databases)
- Ordered graceful shutdown across at least two machines, with timeouts and forced stops as a last resort
- Automatic restart when power is stable, with health checks per service and an alert if one fails
- An outage log with duration, battery used and any service that did not stop cleanly
- A month-long test in a real office or a lab with simulated outages
If you have time left
- Shedding non-essential services early to stretch battery time for the essential ones
- Using the published load shedding schedule to prepare before a planned outage
- A small web dashboard on a phone
- Coordinating with a generator start signal
The problem: the power goes, and the server goes with it
Many small offices in Pakistan run something important on a machine in a cupboard: an accounting database, a clinic's patient system, a school's file server, a small Proxmox box with a few virtual machines. Scheduled and unscheduled load shedding means the power goes several times a day in many areas. A UPS or a solar inverter keeps things running for a while, but when the battery runs out, everything dies at once.
Dirty shutdowns corrupt databases, break virtual machine disks and leave services half started when power returns. Someone has to come in, notice the problem and fix it, often the next morning. Most offices either ignore the risk or ask a staff member to shut things down by hand, which does not happen at 2 a.m.
What already exists and the gap
- Network UPS Tools (NUT) is the standard open source way to read UPS status and trigger a shutdown on low battery. It is reliable but focused on shutting a machine down, not on ordering many services.
- Scripts such as proxmox-ups-shutdown and PVE-UPS shut down Proxmox guests on power failure with configurable waits.
- Vendor UPS software shuts down the machine it is connected to, and sometimes a few more.
- Inverters popular in Pakistan often expose battery data over USB, serial or a Wi-Fi app, but nothing connects that data to the servers.
The gap is a small orchestrator that treats the office as one system: it understands that the web app must stop before the database, that the NAS must be up before the VMs that mount it, uses real runtime estimates rather than a fixed percentage, and checks everything is healthy afterwards.
Inspiration
"Dynamo: Facebook's Data Center-Wide Power Management System" by Qiang Wu and colleagues (ISCA 2016) describes monitoring the whole power hierarchy of a data centre and making coordinated decisions about which servers to cap, so that limited power is used safely. This project brings the same idea, coordinated decisions under a power limit, down to the scale of one office with one battery.
What you build
- Office owners or IT helpers describe their machines and services once in a simple file.
- During an outage, the orchestrator watches the battery, estimates time left and starts a staged shutdown with enough margin, notifying someone on their phone.
- When power returns and stays stable for a few minutes, it starts services in order, checks each one and reports "all back" or exactly what failed.
The technically interesting part
- Estimating runtime honestly. Battery percentage is misleading, especially on ageing batteries and lead-acid inverter batteries. Learn the discharge curve from past outages and the current load, and keep a safety margin.
- Ordering. Represent services and machines as a dependency graph and compute shutdown and startup order, including across machines (stop VMs on host B before stopping the storage on host A).
- Graceful, then firm. Ask each service to stop cleanly, wait with a timeout, then force it. Log which services needed force so they can be fixed.
- Flapping power. Power often returns for a minute and then goes again. Wait for stable power before restarting, and handle an outage that starts in the middle of a restart.
- Health after restart. "Container is running" is not "app works". Add simple health checks: a database accepts a query, a web page returns 200.
How to evaluate it
- Simulated outages: a lab setup with a UPS you can unplug, or simulated battery readings, run 50 times with different timings. Count clean shutdowns and successful restarts.
- Real office: with permission, run for a month and record outages, data problems and manual fixes needed before and after.
- Runtime estimate accuracy: predicted against actual minutes left in test discharges.
Suggested plan
- Weeks 1 to 3: NUT setup with a real or simulated UPS; read an inverter's data.
- Weeks 4 to 6: dependency file, graph ordering and single-machine shutdown.
- Weeks 7 to 9: multi-machine shutdown, restart and health checks.
- Weeks 10 to 12: runtime estimation, alerts and outage log.
- Weeks 13 to 15: month-long or intensive test, documentation and report.
Path to a product
Small offices, clinics, schools and IT service companies across South Asia, Africa and other places with unreliable power face the same problem. A packaged appliance image with setup by local IT providers, or a supported version for managed service providers looking after many offices, is a realistic business.
Scope warning
Never test forced shutdowns on a machine holding real data without backups. Do not design electrical hardware; read data from existing UPS and inverter interfaces only. Support one virtualisation platform plus Docker first.
Learn what you need on Sefism
- Linux, terminal and Git roadmap: services, systemd and shell scripting.
- Linux, terminal and Git cheat sheet: the commands you will use daily.
- DevOps and cloud roadmap: containers, virtual machines and health checks.
- Docker Docs: Get Started: stopping and starting containers cleanly.
- Linux Upskill Challenge: practical server administration practice.
Get help with this idea
This is a good first DevOps project with a very real user. Tauseef can help you design the dependency file, plan outage tests safely and find an office willing to pilot it. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.