---
name: cehoproxy_alias_process_name
description: "CehoProxy: демон, запущенный короткой командой chp, система называет «chp» — проверка по имени процесса должна знать оба имени"
metadata: 
  node_type: memory
  type: project
  originSessionId: cf75944b-cc91-4988-aab6-28363391917a
  modified: 2026-08-07T15:44:21.964Z
---

Поймано живьём в Linux-VM 07.08.2026, [[cehoproxy_overview]].

`DaemonControl.RunningPid` сверяет pid из файла с живым процессом по имени — защита от переиспользования pid. Проверка была `ProcessName.Contains("ceho")`. Но короткая команда `chp` — это **симлинк** на `cehoproxy`, и ядро показывает процесс под тем именем, которым его запустили: `ps -eo comm` даёт `chp`. Продукт сам же учит писать `sudo chp daemon` — и после этого:

- `chp status` и панель показывали **«защита выключена» при работающей защите**;
- `chp stop` не находил кого останавливать;
- `uninstall` снимал файлы, но **оставлял службу и туннель жить**.

Внешне это выглядело как «туннель поднялся сам по себе»: интерфейс `ceho-tun` есть, служба «не работает». Диагноз дал `ss -lptn "sport = :8899"` — он показал держателя порта с именем `chp`.

**Правило:** если продукт ставит алиас-симлинк, любая проверка «наш ли это процесс» обязана знать ВСЕ имена запуска (`cehoproxy` и `chp`), а не одно. На Windows такого нет: `chp.cmd` запускает `cehoproxy.exe`, и имя процесса остаётся полным.

Заодно: `chp stop` теперь не только шлёт сигнал, но и убирает следы аварийного завершения (осиротевший движок, интерфейс, правила `ip rule`) — раньше снять такое состояние было нечем, а `status` про него молчал.
