fix: validate command lock process identity

[UmiSlat]

Problem

External command locks previously stored only the CLI PID and treated
kill(pid, 0) == 0 as proof that the original owner was still running.
This is unsafe when a stale lock survives a host reboot and Android reuses
the PID for an unrelated process.

The issue was reproduced with Droidspaces v6.4.5. The host rebooted while
the Debian13.6 container was running, leaving a lock owned by PID 4806.
After reboot, Android reused PID 4806 for com.android.systemui, whose
/proc/4806/comm value was TB_Client.

Trying to stop the container then failed:

Cannot acquire lock: held by process 4806
Cannot stop 'Debian13.6': another command is managing this container

Solution

• Store new command locks as <pid> <proc-start-ticks> <boot-id>.
• Compare the boot ID and /proc/<pid>/stat starttime before accepting an
  existing lock as active.
• Treat PID-only legacy locks as active only when /proc/<pid>/comm equals
  droidspaces.
• Continue reading PID-only and PID plus starttime lock formats.
• Fall back to PID plus starttime, then PID only, when procfs identity
  metadata is unavailable.
• Preserve conservative behavior when a live process exists but procfs
  identity cannot be read.
• Apply the same ownership checks during acquisition, release, and monitor
  cleanup.
• Share the proc starttime parser with the existing socketd code instead of
  maintaining duplicate implementations.

Compatibility

• Older Droidspaces versions still read the leading PID from the new format.
• Existing PID-only locks remain readable.
• Same-PID command handoff behavior is preserved.
• No new syscall or kernel 5.x interface is required.
• Lock creation degrades gracefully when boot ID or starttime metadata is
  unavailable.
• Container PID files, metadata, scripts, and migration behavior are unchanged.

Testing

Regression harness:

36 checks, 0 failures
36 checks, 0 failures (UBSan)

The shared proc starttime parser was also tested with spaces and ) inside
the process command name:

proc starttime parser checks passed
proc starttime parser checks passed (UBSan)

GitHub CI passed on the final commit:

• musl backend builds for aarch64, x86_64, armhf, x86, and riscv64
• unified tarball and Debian packages
• Android release APK
• artifact staging and upload

CI run:
https://github.com/UmiSlat/Droidspaces-OSS/actions/runs/32350081335

Tested environment

• Device: Xiaomi Pad 8 Pro, model 25091RP04C
• SoC: Qualcomm SM8750P
• Architecture: arm64-v8a
• Android: Android 16, API 36, HyperOS OS3.0
• Kernel: 6.6.77-android15-8-g8d05d8f2439f6-ab10030741-4k
• Userspace: Debian GNU/Linux 13.6 (trixie), aarch64
• Affected Droidspaces version: v6.4.5

The fixed binary has not yet been installed for a complete live container
and host reboot lifecycle test. Kernel 3.10 real hardware has not been tested.

[ravindu644]

Thanks for this, confirmed real. The lock lives on persistent storage, nothing sweeps it at boot, and as root kill(pid, 0) succeeds against any live process, so a reboot mid-command plus Android's dense PID reuse bricks the container exactly as you described.

I landed a smaller version of your fix on dev as 5d20069, with you as co-author. It keeps your core insight but leans on one invariant: a lock holder is always a CLI process, so no lock can legitimately outlive a boot. Locks are now stamped and only that exact format with a matching boot ID and a live PID counts as held. Anything else, including old pid-only locks, is removed and the command proceeds, since a bare PID cannot be told apart from PID reuse. That also made the starttime and comm checks unnecessary. Old binaries still atoi() the leading PID fine.

Verified on device: the reported scenario now self-heals silently and a live lock still blocks a second command. Closing in favor of 5d20069. Thanks again for the excellent report and compatibility analysis.