Re: net/sysmon rc.d script

[Brook Milligan <brook%biology.nmsu.edu@localhost>]

> On Aug 30, 2026, at 06:35, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> Brook Milligan <brook%biology.nmsu.edu@localhost> writes:
> 
>>> On Aug 29, 2026, at 18:27, Greg Troxel <gdt%lexort.com@localhost> wrote:
>>> 
>>> That looks ok, except that pause and resume seem novel and I'm not sure
>>> about the wisdom of defining them first in pkgsrc.  Do you have a
>>> compelling need?
>> 
>> I was just exposing the commands that are offered by the daemon.  It
>> seems reasonable that if someone reads the man page, they might expect
>> those to work via the script.  I have the sense that those are the
>> canonical ways of controlling processes, no?
> 
> That is not a reasonable or documented expectation, and it is not
> consistent with our current practice.  daemons can be far richer than
> the rc system.  The keywords to rc.d scripts are not textually related
> to the keywords used to invoke daemons; the former defines an abstract
> interface and the latter is just how any daemon is.  The point is to map
> the abstract interface to the daemon's behavior.
> 
> Adding random extra rc.d commands is an interface change and should only
> happen with discussion and a broad consensus that it's a good idea.
> 
> You may be being misled about 'reload' which is listed as extra, but
> notice that reload is very common in rc.d, to the point where it should
> be hoisted to be formally part of the interface instead of evolved de
> facto part.

This seems to be an unfortunately restrictive view of the purpose of rc.d scripts.
The rc(8) man page includes the following paragraph:

	rc.d/ is the directory which contains various sh(1) scripts, one for each
     	service, which are called by rc at startup, rc.shutdown at shutdown, and
     	as necessary during system operation to stop, start, restart, reload, or
     	otherwise control the service.

To me, the last phrase seems important and supportive of the idea that the intended 
purpose of rc.d scripts goes beyond the narrow API needed for rc/rc.shutdown themselves.
I feel that these scripts perform much the same purpose as pkgsrc: standardizing an 
otherwise open-coded and potentially inconsistent API presented by a software subsystem 
so that sysadmins can interact with it via a common set of idioms. In the case of rc.d 
scripts, the controlling commands, i.e., sysdamin API, is open, because all the defined 
keywords (start, stop, etc.) may not apply to every daemon and additional daemon-specific 
ones may be appropriate.  In every case, however, the basic interface is the same: 
"/etc/rc.d/daemon keyword”; knowing only what keywords are available replaces the much 
more difficult challenge of deciphering what specific mechanism (e.g., signal, pipe, socket,
whatever) is used to control every daemon.

Thus, if the authors of a daemon have provided a means of controlling the daemon that 
is not found in other daemons but is easily adaptable to commands provided by the 
corrresponding rc.d script, it seems appropriate to make that capability available 
to sysadmins.

Despite that, perhaps this is a minority view.  I would greatly appreciate additional 
discussion on this.

Cheers,
Brook