Interested in System Health Monitor Project

[Sahil Kumar]

Hi ,my name is Sahil Kumar (GitHub: Sahilll10). I am a third-year Computer Science student writing to introduce myself and express interest in the System Health Monitor project for GSoC 2026.

Prior contributions to Qubes OS:

• qubes-core-admin-client#450 — Merged by @marmarek — tests: mock_app: register per-VM admin.vm.List call. Commit 84edd42 changed .klass to use a per-VM admin.vm.List call, causing 9 test failures across qubes-desktop-linux-manager. I traced this via git bisect, identified the missing per-VM registration in MockQube._add_to_vm_list, and fixed it in 4 lines — resolving all failures without per-test duplication. Linked to qubes-issues#10770.
• qubes-desktop-linux-manager#300 — Open, under review by @ben-grande — devices widget: open file manager on dispvm block attach. Adds automatic file manager launch inside a DispVM when a block device is attached, using the qubes.StartApp+qubes-open-file-manager qrexec service. Includes a full MockQubesComplete-based test suite covering both AttachDisposableWidget and DetachAndAttachDisposableWidget. pylint and black CI passing.
• qubes-desktop-linux-manager#303 — Open, under review by @marmarta — global config: move dom0 link to first paragraph in filecopy section. Fixes an unclickable hyperlink trapped inside a GtkRadioButton that intercepted click events. OpenQA ran and reported no failures. Tested locally using the GTK mock setup from the developer docs.

Why System Health Monitor:

Working across these three PRs gave me direct hands-on experience with the exact stack this project requires — PyGTK widgets (qui/devices/, qubes_config/global_config/), Python, qrexec services, and the Qubes admin API via MockQubesComplete. What I found during this work is that there is no unified, user-visible signal when something goes wrong in the system — a DispVM crash, a VM running out of memory, or an insecure USB configuration in dom0 is either silently logged somewhere or surfaces only through confusing behavior.

My plan for the summer:

1. Audit existing scattered health signals — disk space widget, update widget, qubesadmin API properties — and define a unified data model for system state
2. Design and implement a background service that polls for common issues: storage pressure, memory, crashed system VMs, insecure USB config, pending updates
3. Build a PyGTK tray widget that presents a terse system state overview and triggers notifications when something bad happens — consistent with the existing qui/ widget architecture
4. Write unit tests using MockQubesComplete for all health check logic
5. Write integration tests and user/developer documentation

Question for the community: As I go deeper into researching the existing health signal surface — reviewing the update widget, disk space widget, and qubesadmin API — where is the best place to share intermediate findings and get directional feedback before writing the formal proposal? Should I post incremental findings to qubes-devel, open issues on qubes-issues, or use the forum? I want to make sure I am moving in the right direction early.

I am comfortable working independently, communicating daily, and submitting weekly formal updates to the list. I am in IST (UTC+5:30) and have no conflicting commitments during the GSoC period. I am not submitting proposals to other organizations — Qubes OS is my first and only choice.

GitHub: https://github.com/Sahilll10

Thank you for your time.

Sahil Kumar