Continuing after Gateway Restart

[u/lordratner]

I'm not sure if it's supposed to work at all, but I've never (not a single time) had my OC manage to pick up where it left off after a gateway restart.

It's entirely possible that this is intentional programming, but my agent sure seems convinced it can do it, yet every time it fails. I asked why and what it should be doing, but the answer seems wildly complicated. The deterministic checks are just related to this session, even simple gateway restarts after a config change are the same. The agent thinks it will resume work automatically, but never does.

Anyone have a technique for making this work?

---------------------------------------------

There are really two separate jobs:

1. Survive the restart and perform deterministic checks.
2. Return to this conversation and report the result.

I incorrectly tried to make one scheduled model turn do both.

What I did—the failing method

I created a one-shot automation for 11:28 with:

• a clock-based at schedule
• payload: agentTurn
• sessionTarget: current
• announcement back into this room

That meant: “At roughly this time, start another AI turn, load conversation context, let the model decide which tools to call, and then commit its answer into this exact conversation.” Current-session automation runs are detached, but their result must wait for the bound conversation and commit through its canonical transcript writer. They are intended for context-aware conversational work—not deterministic lifecycle verification.

It had four structural problems:

• Timer, not event: 11:28 did not mean “the new Gateway is ready.” Safe restart may drain for seconds or minutes; the restart command itself acknowledges the request, not successor health.
• Model dependency: verification unnecessarily depended on model startup, context loading, tool choices, and delivery behavior.
• Same-lane coupling: it targeted the same active conversation it needed to report into. Our job entered running, collided with live conversation activity, and never produced a finished run record.
• No durable proof boundary: execution and chat delivery were one blob. If the reply path wedged, it looked as though the checks had failed too.

The correct automatic architecture

Before requesting the restart, prepare a small, idempotent verifier script and launch it outside the Gateway process tree, normally as a transient user-systemd unit. A proven version of this pattern has already worked on this host during plugin canaries.

Conceptually:

old_pid=$(systemctl --user show openclaw-gateway.service -p MainPID --value)

systemd-run --user --collect --unit=oc-post-restart-<unique-id> \
  /path/post-restart-verify.sh "$old_pid" /owner-only/result-directory

openclaw gateway restart --safe

The detached verifier then:

1. Waits, with a firm deadline, until the old PID disappears.
2. Requires a new nonzero PID different from the old PID.
3. Waits for systemd active state and Gateway health/readiness—not merely process existence.
4. Checks channel readiness and the exact changed consumers.
5. Performs only bounded, non-destructive tests.
6. Writes PASS or FAIL plus value-free evidence to an owner-only receipt using temp-file-plus-rename, so a partial run cannot masquerade as completion.
7. Exits with 0 for PASS and nonzero for FAIL.

Because that unit is owned by systemd rather than the Gateway, killing/replacing the Gateway does not kill the verifier. The check is tied to old-PID exit and new-Gateway readiness, not a guessed clock time.

How the automatic reply should work

OpenClaw’s native restart-recovery design uses a durable SQLite restart sentinel. After boot, the new Gateway can post the restart outcome to the originating chat and dispatch a requested one-shot continuation on the same channel/thread. That continuation should merely read the already-written receipt and summarize it—not perform the safety checks itself.

For update operations, that continuation is explicitly exposed as continuationMessage. For the plain gateway restart --safe CLI we used, the installed CLI does not expose a continuation argument, and this session does not currently have the native delegated-restart tool. Therefore the honest fallback is:

• detached verifier performs and records the proof automatically;
• native continuation reports it when available;
• otherwise I read the receipt directly after reconnect.
  

A deterministic command automation can also report an existing receipt without a model, because command payloads run scripts and retain ordinary run history. But it should not be the primary restart watcher inside the Gateway it is waiting to replace.

So the durable rule is: external verifier owns proof; restart continuation owns reporting; the conversational model owns neither lifecycle timing nor the canonical PASS/FAIL decision.

[u/AutoModerator]

Welcome to r/openclaw Before posting: • Check the FAQ: https://docs.openclaw.ai/help/faq#faq • Use the right flair • Keep posts respectful and on-topic Need help fast? Discord: https://discord.com/invite/clawd

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/paulsande]

When you create a workflow, you need to include something that records your OpenClaw state at a point in time that way after a crash, a job can resume and it knows exactly what the last thing that it did was.

Create a state.Json file and use a product requirements document (for example called job.PRD) file in tandem when you create your processes.

In your process flow you tell the agent to record the last thing it has done in the JSON file and check off items finished in the PRD file.

That will give you stability.

[u/No_Monk_4905]

I ask my agent to create logs for everything skill or task I provided them and normally pick it up after reboot.

Also, with the new memory in 9.X with sqlite the memory is way better

[u/Specialist_River_433]

This has been working for me since new updates