`ocx service install` fails on CentOS 7.6 due to unsupported systemctl --value flag

[spinachomes]

Client or integration

Other

Area

Installation or packaging

Summary

When running ocx service install on CentOS 7.6, the command fails with an error related to the systemctl --value option.

Reproduction

1. Environment: CentOS 7.6、 Node.js 22.x installed via non-official build with glibc version: 2.17
2. Run command: ocx service install

Version

2.34.0

Operating system

CentOS 7.6

Provider and model

No response

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[spinachomes]

❌ Service install cleanup failed: Command failed: systemctl --user show opencodex-proxy --property=LoadState --value
systemctl: unrecognized option '--value'

[Ingwannu]

Confirmed on current dev (e546c160b). The Linux install-cleanup path in src/service.ts still invokes systemctl --user show opencodex-proxy --property=LoadState --value; systemd 219 rejects --value, while the repository’s service-manager probe already uses the compatible key/value form. I will replace this one cleanup query with -p LoadState, parse the explicit LoadState=... property, preserve the existing fail-closed behavior for empty/malformed or unreachable-manager output, and add a focused legacy-systemd regression. I’ll link the PR and exact validation here; this issue should remain open until the fix lands.

[Ingwannu]

Fix opened as #2867 against dev. Exact head 46a7a56bb removes the unsupported --value option, validates explicit LoadState= output, and keeps malformed or unreachable-manager results fail-closed. Focused service/systemd tests pass 200/200; the issue remains open until the PR is reviewed and merged.

[lidge-jun]

리뷰 · 우선순위 70 / 80

이 이슈는 CentOS 7.6에서 ocx service install이 설치 정리 단계에서 바로 죽는다는 보고입니다. 본문 로그칸은 비어 있지만, 댓글에 실제 에러가 있습니다. systemctl --user show opencodex-proxy --property=LoadState --value를 쳤더니 systemctl: unrecognized option '--value'가 나옵니다. 환경은 systemd 219, Node 22, glibc 2.17입니다.

지금 dev(HEAD e546c160b, 마지막 머지 #2859)의 Linux 설치 정리는 src/service.ts platformServiceInstallCleanupOps입니다. prepareServiceInstall이 새 유닛을 쓰기 전에, 매니저가 아직 들고 있는 리스너를 멈추려고 이 프로브를 부릅니다. 없는 유닛과 매니저 고장을 구별하려고 show LoadState를 쓰는데, 값만 받으려고 --value를 붙였습니다. systemd 219는 -p / --property는 알아도 --value는 모릅니다. sh()는 종료 코드가 0이 아니면 던지므로, 유닛이 있든 없든 첫 설치가 ❌ Service install cleanup failed로 끝납니다.

같은 저장소의 소유권 프로브(src/service-manager-probe.ts inspectSystemd)와 systemdNeedsDaemonReload는 이미 -p와 키=값 줄을 읽습니다. 설치 정리만 --value를 쓰고 있었습니다. 고치는 방향은 --value를 빼고 LoadState= 키가 있는 줄만 인정하는 것입니다. 값이 not-found일 때만 없다로 보고, 빈 출력이나 깨진 출력은 던집니다. 그 수정이 #2867로 열려 있고, 베이스는 지금 HEAD와 같습니다.

이 이슈만으로 카탈로그나 types/config 분할을 건드릴 일은 없습니다. 설치 경로의 오래된 systemd 호환 버그입니다. --value를 고친 뒤에도 CentOS SSH 세션에서 사용자 버스(XDG_RUNTIME_DIR)가 없으면 다음 에러가 날 수 있습니다. 그건 이번 리포트의 직접 원인은 아니고, 설치 쪽은 installSystemd에서만 ensureUserBusEnv()를 부릅니다.

경로 src/service.ts platformServiceInstallCleanupOps Linux status - 현재 HEAD는 --property=LoadState --value를 그대로 씁니다. systemd 219에서 설치가 시작도 못 하는 직접 원인입니다.
경로 src/service-manager-probe.ts inspectSystemd - 이미 -p LoadState 키=값 파서를 씁니다. 설치 정리만 뒤처져 있습니다.
경로 prepareServiceInstall / installServiceSafely - 정리 프로브가 던지면 ❌ Service install cleanup failed로 끝나고 유닛 파일을 쓰지 않습니다. 이슈 증상과 맞습니다.
경로 #2867 - --value 제거, LoadState= 파싱, fail-closed 유지, 회귀 테스트가 들어 있습니다. 이 이슈의 정본 수정입니다.
경로 사용자 버스 - --value 다음으로 SSH/linger 환경에서 터질 수 있는 후속입니다. 이번 이슈를 열어 둘 이유는 아닙니다.

메인테이너의 판단이 필요한 지점

• #2867을 이 이슈의 정본 수정으로 보고 머지와 함께 닫을지
• 사용자 버스 env를 같은 이슈에 묶을지, 후속 이슈로 나눌지
• 머지 전에 실제 CentOS 7.6 재현을 필수로 둘지

너의 추천
#2867을 머지한 뒤 이 이슈를 닫으세요. 원인과 수정이 한 줄로 연결됩니다. 사용자 버스는 후속으로 두세요. types/config 분할과 무관합니다.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Fixed on dev in #2869 (8d1dc1f5d). Three separate systemd-version incompatibilities were involved, not just the one in your traceback.

The flag you hit. systemctl show --property=LoadState --value — --value arrived in systemd v230, and CentOS 7 ships v219. The call sits in the install cleanup path, which runs before anything is installed, so execSync threw, the install branch caught it, printed the message you saw, and exited without installing.

Worth noting since it is the non-obvious part: simply dropping --value would have been worse than the crash. The old code lowercased the whole output, so LoadState=not-found became "loadstate=not-found" — a non-empty string, which the cleanup path reads as the unit exists. It now parses the value out of show -p LoadState explicitly, which works on v219 and on current systemd alike, and still fails closed on a missing or empty property.

Two more that would have bitten you next. systemctl disable --now (--now added v220) is used during uninstall, and its failure was swallowed by a catch — so on v219 the unit file could be deleted without the service ever being stopped or disabled. It is now a separate best-effort stop followed by disable. And StandardOutput=append: / StandardError=append: (added v240) are silently ignored on v219, which means the service.log the docs promise would have stayed empty; the redirection moved into the ExecStart command instead.

What was not verified. No CentOS 7 host was available. The v219 behavior is established from the systemd source tags where each flag was introduced (v220 --now, v230 --value, v240 append:) and exercised through an injected command runner in tests/service.test.ts, with each fix proven to turn its test red when reverted. It was not run against real systemd 219.

If you can try it after the next release, the useful signal is whether ocx service install completes and whether service.log actually fills. Please reopen if either still fails.