available/ is not a load path: initctl start fails with 69; enable conflates "loaded" with "start at boot" #518

Summary

With the distro layout (/etc/finit.d/available/ + /etc/finit.d/enabled/), a .conf in available/ with no symlink in enabled/ is never loaded, so initctl start refuses to start it.

Reproduced on 4.17 and 5.0-rc1 (both built from source and run as PID 1).

So initctl enable/disable does not mean "start / don't start at boot" — it means "load / unload". Finit therefore cannot express "registered, startable/stoppable at any time, but not started automatically at boot" except by hard-coding manual:yes / manual-start = true inside the .conf file. In systemd these are orthogonal; in Finit they are coupled through the enabled/ symlink.

Why it matters

Three properties that should be independent are collapsed into one switch:

Impact for multi-product integration: the same service must start at boot on product A but not on product B, must always be startable/stoppable, and the customer must be able to toggle "start at boot". Today there is no clean way:

• "not at boot + startable" → must be symlinked into enabled/ and carry manual-start inside the file.
• Toggling boot intent at runtime → either rewrite the .conf + reload, or initctl enable/disable + reload, where disable also unloads the service and takes away runtime control — the opposite of "just don't autostart".

A symptom of the same conflation: 5.x doc/distro.md describes enabled/ as "symlinks to configurations that should start at boot", while the implementation treats it as "configurations to load".

Suggested fix

On-demand loading (systemd-like). If initctl start <name> names something not in the runtime table but present in available/, load that .conf and start it, without persisting enable state. This alone makes enable/disable mean "start at boot" again and restores orthogonality.