bug: deploy.sh starts duplicate process — cobot responds twice #139

New issue

Closed

opened 2026-02-27 11:27:38 +00:00 by Zeus · 0 comments

Zeus commented

2026-02-27 11:27:38 +00:00

Collaborator

Bug

After CI deploy, two cobot processes run simultaneously:

One as alpha (correct)
One as root (duplicate)

Both poll Telegram, causing Alpha to respond twice to every message.

Root Cause

The deploy.sh script does exec sudo -u alpha $0 when running as root. But the deploy workflow (or authorized_keys command restriction) may spawn the script in a way that creates two processes. Additionally, the PID file check may not prevent the second instance because:

The first process writes PID, then the root process starts before the alpha process PID is written
Or the exec sudo doesn't fully replace the root process

Evidence

alpha    1028060  cobot run   # correct
root     1028124  cobot run   # duplicate

Expected

Only ONE cobot process should run after deploy. The deploy script should:

Kill any existing process first (both root and alpha-owned)
Ensure only one instance starts
Verify single-instance after restart

Workaround

Manually kill the root process after each deploy.

## Bug After CI deploy, two cobot processes run simultaneously: - One as `alpha` (correct) - One as `root` (duplicate) Both poll Telegram, causing Alpha to respond twice to every message. ## Root Cause The `deploy.sh` script does `exec sudo -u alpha $0` when running as root. But the deploy workflow (or authorized_keys command restriction) may spawn the script in a way that creates two processes. Additionally, the PID file check may not prevent the second instance because: 1. The first process writes PID, then the root process starts before the alpha process PID is written 2. Or the `exec sudo` doesn't fully replace the root process ## Evidence ``` alpha 1028060 cobot run # correct root 1028124 cobot run # duplicate ``` ## Expected Only ONE cobot process should run after deploy. The deploy script should: 1. Kill any existing process first (both root and alpha-owned) 2. Ensure only one instance starts 3. Verify single-instance after restart ## Workaround Manually `kill` the root process after each deploy.