Delete VMSLNMD.EXE: VMS has no logical name daemon (vms-a4b) - #11
Merged
Merged
Conversation
OpenVMS keeps the logical name tables in the executive. There is no logical
name server process, no socket, and nothing for a manager to start. OVMX had
invented one anyway: VMSLNMD.EXE listened on /tmp/ovmx/lnm.sock, loaded
SYS$MANAGER:SYLOGICALS.CONF into its own private manager, and served ZERO
clients product-wide — a grep for connect()/LNM_SOCKET_PATH across src/ and
tools/ found no caller. PID 1 forked it, stat()'d the socket for up to 2s, and
printed "%STDRV-I-LNMSTART, logical name daemon started" — an invented message
announcing a process whose only observable effect was that announcement.
Under project Rule 10 that is the illegal third answer: a plausible-looking
facility for something VMS never has. Two legal answers only — match VMS, or
hide it. There is nothing to match, so it is deleted rather than reduced.
Deleted:
- src/vmslnm/lnm_daemon.c and the VMSLNMD.EXE CMake target/install
- start_lnm_daemon(), wait_for_lnm_socket(), LNM_SOCKET_PATH and the
%STDRV-I-LNMSTART banner line in PID 1; boot steps renumbered
- VMS_LNMD_PATH from ovmx_layout.h, VMSLNMD.EXE from provision_symlinks()
and from the initramfs copy list in distro/Dockerfile.bootable
Coverage held, not dropped: verify_imgact_cmake{,_x86_64}.sh checked three
dynamic images for PT_INTERP=IMGACT.EXE + DT_HASH and one of them was
VMSLNMD.EXE. HELP.EXE takes its place, so both CI jobs still assert three.
This does NOT make logical names system-wide — it only removes the pretense
that something already did. LNM$SYSTEM/GROUP/JOB are still per-process
calloc'd tables (lnm_client.c:140). Making them executive-resident is blocked
on the operator ruling in vms-ln0 (waiting in `rd gates`); vms-d37 is the
implementation item.
Refs: vms-a4b, vms-ln0, vms-d37
Re-dispatch after veracity review found the deletion incomplete outside code: - distro/rootfs/.../OVMX.CONF still shipped LNM_SOCKET into the running rootfs, configuring a daemon nothing reads (product-wide grep for readers of the file's own keys, not just LNM_SOCKET, found zero). - docs/architecture.md (rank 2 in the source-of-truth hierarchy, above CLAUDE.md) still documented vmslnmd as a live boot step in both the legacy Docker sequence and the QEMU-mode sequence, plus the layer diagram, dependency graph, and component table. - docs/building.md still listed vmslnmd among produced executables. - distro/Dockerfile.bootable's slim-initramfs comment still named LNMD. - src/vmslnm/lnm_client.c's header comment still promised a future socket-based daemon client; repointed at the open vms-ln0 ruling. - VMS_LNM_CONF_PATH (ovmx_layout.h) is now a zero-reader constant; marked reserved for the executive-resident work rather than left silent, per the re-dispatch ruling. Re-ran the grep audit honestly across src/ tests/ tools/ distro/ .github/ docs/: remaining hits are explanatory comments referencing the deletion (ovmx_layout.h, vmslnm/CMakeLists.txt) and the already-marked SUPERSEDED historical section of docs/design-image-activation.md. Built distro/Dockerfile.bootable with podman and ran tests/qemu/test_persistent_boot.sh under pure TCG (no /dev/kvm, no host kernel headers needed): 12/12 checks passed across both the fresh-install boot and the persistent-reboot boot, confirming the PID 1 / initramfs rewrite from the prior commit still boots correctly. All changes in this commit are comments/docs/config only — no C source logic changed, so the existing test baseline is unaffected. vms-a4b
baron-3dl
added a commit
that referenced
this pull request
Aug 7, 2026
…negctl fixture, attribution race) (#164) Four tests were red on main. Three were deterministic reds hidden behind "flaky"/unowned labels; one was a genuine concurrency race. Full suite is 113/113 green under `ctest -j` after these fixes. x86_64_reloc_survey_fresh (#24): docs/design-link-x86_64-relocs.md went stale after sys_uai.c pulled in vms_kif.h. The survey's include list is built from src/<c>/include per component, and src/libvmssys has no include/ subdir, so 8 libvmssys-dependent TUs failed to compile standalone and silently dropped from the surveyed set. Add -I$REPO/src/libvmssys and regenerate (72obj/13fail -> 80obj/5fail; remaining 5 are unrelated missing-header cases). awk/tooling logic otherwise unchanged. userspace_service_register (#11): the gate walked $SRC_ROOT with a raw `find`, descending into gitignored .claude/worktrees/ (parallel repo checkouts) and reading their add_subdirectory()/install() as this tree's, flagging escapes that belong to stale checkouts. Scope all three CMakeLists.txt walks to git-tracked files via `git ls-files`, with a .claude-pruned `find` fallback for non-git trees. "The product tree" == tracked source; not a silent skip. userspace_service_register_negctl (#12): two stacked bugs in the register_buildset.awk PARTIAL-parse control, deterministically red (identical on a pristine HEAD worktree), not flaky. (a) The malformed fixture did `sed '$d'`, deleting the trailing array ']' instead of the entry's '}', so the parser's "file"-vs-"}" balance stayed even and never tripped. (b) Once (a) was fixed the awk correctly refused with its diagnostic on stderr (by design; the real gate splits stdout/stderr), but the control captured stdout only, so its "named reason" grep saw an empty string. Fix both; register_buildset.awk is unchanged. facility_attribution_negctl (#111): section G derived the host site list by running the instrument against the LIVE shared checkout, then diffed it against the container side — a snapshot frozen into the image at build. A concurrent write to the checkout mid-run (another test or another session) skewed the diff, producing a different spurious mismatch every run (the "different symptom every run" flaky signature). Run the frozen $WORK/pristine snapshot on both sides so a real image/tree divergence still reds but a mid-run edit cannot. No test weakened, no retries/sleeps, committed execution record untouched. Closes vms-354, vms-53f, vms-60c, vms-2d4; completes vms-aa6. Co-authored-by: alice <alice@workspace.local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deletes the pretense, not the problem.
vms-a4bhad two halves; this is the one that could be done now.What this is
VMSLNMD.EXElistened on/tmp/ovmx/lnm.sockwith zero clients product-wide. A grep forconnect()/LNM_SOCKET_PATHfound no caller anywhere insrc/ortools/. The only other reference wasovmx_init.c, whichstat()ed the socket purely to decide whether to print%STDRV-I-LNMSTART— so PID 1 announced a daemon whose sole observable effect was that announcement.On OpenVMS, logical name tables are in the executive. There is no logical name server process and nothing to start. Moving the daemon launch into
SYSTARTUP_VMS.COMwould have been theatre, so it was deliberately not done.+35 / −522 across 15 files:
lnm_daemon.c(415 lines), the CMake target and itsinstall(TARGETS),LNM_SOCKET_PATH,start_lnm_daemon(),wait_for_lnm_socket(), thelnm_pid/lnm_startedplumbing and its distantkill()/waitpid()cleanup,VMSLNMD.EXEfromprovision_symlinks(), thedisplay_boot_banner()parameter,VMS_LNMD_PATHfromovmx_layout.h, and thecpindistro/Dockerfile.bootable. Plus the config and doc sites that still referenced it — includingOVMX.CONF, which was shippingLNM_SOCKET=/tmp/ovmx/lnm.sockinto the running rootfs.It also deletes an invented message:
%STDRV-I-LNMSTART, logical name daemon startedhad no OpenVMS oracle behind it.What this is NOT
This does not make logical names executive-resident.
DEFINE/SYSTEMin one process is still invisible to others —lnm_client.cstillcallocs private tables. That work isvms-d37, correctly blocked behindvms-ln0, which is awaiting an operator ruling on placement (ioctl-per-translation vs. an mmap'd arena) and defers four VMS values that Rule 10 bars an agent from self-certifying.src/vmslnm/lnm_client.cis retained and still builds.Verification
ctest39/39 passed, 0 failed, 0 skipped. Rebased onto main aftervms-71a(#10); thedocs/architecture.mdconflict resolved in favour of main's deletion of the Docker Mode section.🤖 Generated with Claude Code