Refresh unit requests and preserve shared compilation across runtime shutdown

userland/init/README.md

@@ -32,7 +32,7 @@ Each request uses a unique identifier.
 
 1. The client watches `/run/systemd/replies/<id>` before it submits the request.
 2. The client writes `/run/systemd/requests/<id>.json`.
-3. Init reads the request and applies the action.
+3. Init reads the request, rescans the unit folders, and applies the action.
 4. Init writes `/run/systemd/replies/<id>` and removes the request.
 5. The client reads and removes the reply.
 
@@ -42,6 +42,8 @@ Request example:
 {"action":"start","unit":"example.service"}
 ```
 
+Requests observe unit files that the client writes before it submits the request.
+A queued watcher event does not delay the definition that the request uses.
 Actions are `start`, `stop`, and `restart`.
 A reply acknowledges the action. It does not imply that the service completed its start or stop.
 The control tools then wait for the requested state. A failed start returns code 1.

userland/init/src/main.rs

@@ -339,6 +339,8 @@ fn controls(services: &mut BTreeMap<String, Service>) {
         let Ok(request) = serde_json::from_slice::<Request>(&bytes) else {
             continue;
         };
+        // A unit edit can arrive after the event loop's scan but before this request.
+        scan(services);
         let mut reply = Reply {
             code: 0,
             text: String::new(),