when going into reboot mos_sysvol ot the volmgr should umount the volumes just before the system stops #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implementation Spec for Issue #1: Unmount Volumes on Reboot/Shutdown
Objective
Ensure that MOS storage volumes (both sysvol-managed system volumes and volmgrd-managed dynamic volumes) are cleanly unmounted during system reboot or shutdown, just before the system stops.
Architecture (Current State)
do_shutdown()→ stops services → reaps zombies →sync()→reboot()syscallmos_sysvol::unmount()library function — currently unused at shutdownaccept()Gap: Neither sysvol unmount nor volmgrd unmount is called during shutdown.
Requirements
sync()+reboot()Files to Modify/Create
mos_volmgrd/src/main.rsmos_volmgrd/src/rpc/server.rsrun_serveraccept loopmos_volmgrd/Cargo.tomlsignalfeaturemos_sysvol/src/main.rs--unmountsubcommandmy_init_pid1/src/main.rsmos_sysvol --unmountindo_shutdown()my_init/etc/my_init/system/volmgrd.tomlImplementation Plan
Step 1: Graceful shutdown for mos_volmgrd
signalfeature to Cargo.tomlrun_serverto accept a shutdown receiver and usetokio::select!main.rsthat unmounts all registry mounts then exitsStep 2: Add
--unmountsubcommand to mos_sysvol binarymain.rsto accept--unmountflag--unmount, callmos_sysvol::unmount()and exitStep 3: Add sysvol unmount to PID 1 shutdown
do_shutdown(), after services stopped and zombies reaped, spawnmos_sysvol --unmountStep 4: Add volmgrd service definition
volmgrd.tomlwith dependency onsysvolAcceptance Criteria
mos_sysvol --unmountafter services stop, before sync/rebootNotes
mos_sysvol --unmountbinary approach (recommended) to avoid cross-workspace dependencymos_sysvol::unmount()already exists and handles correct orderingdo_shutdown()already has a tokio runtime availablethere is of course some dependencies to be verified... imagine a process managed by my_init didn't get shut down properly because of ... reasons.. the fs can't really be umounted (except lazy umount) we shouldn't dwell on that and if that happens do a sync before reboot
Test Results
Failure Details
my_init —
harness::tests::test_harness_starts_and_stopsThe integration test harness failed because the
my_init_serverbinary was not found. The test expects the binary to be pre-built withcargo build --features server --releaseor theMY_INIT_SERVER_BINenv var to be set. This is an environment/setup issue, not a code bug.Implementation Summary
Changes Made
mos_volmgrd — Graceful shutdown with SIGTERM handling
crates/mos_volmgrd/Cargo.toml: Added tokiosignalandsyncfeaturescrates/mos_volmgrd/src/rpc/server.rs:run_servernow accepts a shutdown channel; usestokio::select!to stop accepting connections on shutdowncrates/mos_volmgrd/src/main.rs: Registers SIGTERM handler. On signal: sends shutdown to server, iterates registry entries in reverse, unmounts each (with lazy unmount fallback), cleans up socket filemos_sysvol —
--unmountsubcommandcrates/mos_sysvol/src/main.rs: Added--unmountflag. When invoked, callsmos_sysvol::unmount(), logs result, exits cleanly even on failuremy_init_pid1 — Shutdown integration
crates/my_init_pid1/src/main.rs: Indo_shutdown(), after zombie reaping and beforesync(), invokes/usr/bin/mos_sysvol --unmount(non-container mode only). Failures logged as warnings, never block reboot.Service definition
etc/my_init/system/volmgrd.toml: New service definition for mos_volmgrd daemon, depends onsysvolShutdown Sequence (after changes)
mos_sysvol --unmount→ unmounts system volumessync()reboot()syscallDesign: Resilient unmount
sync()always runs before reboot regardlessTest Results
Implementation Committed
mos_volmgr (main branch):
8895ab08895ab0my_init (development branch):
cc806aageomind_code/my_init@cc806aaBoth commits reference this issue.