mirror of
https://github.com/Security-Onion-Solutions/securityonion.git
synced 2026-07-12 12:01:32 +02:00
Josh Patterson
89e6a746c8
Live testing on a standalone node found the previous commit still reported ready on the OUTGOING daemon. Reproduced by running the production sequence: systemctl restart --no-block salt-minion # what service.restart issues /usr/sbin/so-salt-minion-wait # what cmd.run then runs so-salt-minion-wait: gating on pid-tagged ready line ... plus master sockets salt-minion (pid 2750297) ready after 3s # 2750297 is the OLD child salt restarts this unit with --no-block -- _no_block_default() in salt/modules/systemd_service.py returns True when the unit is the salt-minion service -- so service.restart returns as soon as the job is enqueued. Measured on the host, systemd does not swap MainPID until ~7.3s later. Throughout that window the old daemon is still running, still holds its master sockets, and its own ready line is already in the log, so every gate passes on the instance that is about to be torn down. INITIAL_SLEEP=3 expired inside that window. Wait for systemd's job queue for the unit to drain before resolving MainPID. That is deterministic rather than a timing guess: the job exists from the moment --no-block returns until the new instance signals READY, and MainPID is new by the time it clears. Measured transition: t=0.0s job pending, child=OLD, sockets up, ready line present t=7.9s job drained, child=NEW, sockets up, ready line ABSENT t=10.7s ready line for NEW child appears <- script returns here The same run also confirms empirically why the log line is required in addition to the sockets: for 2.8s the new child has both master connections while _post_master_init() is still loading modules and compiling pillar, so a socket-only gate would return that much too early. Correct the comment claim from the previous commit. The --no-block restart is real; it lives in salt's systemd_service module, not in this repo, which is why searching the repo for it turned up nothing.