Overview
Stops the currently running Spacebot daemon gracefully. Waits up to 10 seconds for clean shutdown before timing out.Usage
Behavior
When you runspacebot stop:
- Checks if running: Reads the PID file to verify a daemon is running.
- Sends shutdown command: Uses IPC (Inter-Process Communication) to send a graceful shutdown signal to the daemon.
- Waits for exit: Polls the process for up to 10 seconds, checking if it has terminated.
- Confirms shutdown: Reports success or timeout.
Graceful Shutdown
During shutdown, the daemon:- Completes in-flight message processing
- Disconnects from messaging platforms (Discord, Telegram, etc.)
- Closes all active channels and workers
- Flushes pending database writes
- Stops cron schedulers
- Closes database connections
- Removes the PID file
Examples
Stop running daemon
Daemon not running
Stop and restart
Error Cases
Not running
IPC failure
- PID file exists but daemon is dead (stale PID file)
- Unix socket removed or inaccessible
- Permission issue
ps aux | grep spacebot to verify the process state. If the daemon is truly dead, remove ~/.spacebot/spacebot.pid manually.
Timeout
- Long-running task blocking shutdown
- Deadlock in shutdown code
- Process hung
kill -9 42819 to force termination if necessary, then investigate logs in ~/.spacebot/logs/.
Timeout Behavior
The 10-second timeout is not configurable. If the daemon doesn’t exit within this window:- The
stopcommand exits with an error - The daemon process may still be running
- You should investigate why shutdown is taking so long
Force Kill
Ifspacebot stop times out or fails, you can force-kill the process:
Related Commands
spacebot start- Start the daemonspacebot status- Check if daemon is running
Exit Codes
| Code | Meaning |
|---|---|
| 0 | Daemon stopped successfully |
| 1 | Daemon not running, IPC failure, or timeout |
Implementation Notes
The stop command uses a Unix domain socket for IPC (~/.spacebot/spacebot.sock). The daemon listens for IpcCommand::Shutdown and responds with IpcResponse::Ok before initiating shutdown.
This approach is more reliable than sending SIGTERM because:
- It confirms the daemon received the signal
- It allows the daemon to respond before shutting down
- It provides structured error messages