Re: net/sysmon rc.d script

[Greg Troxel <gdt%lexort.com@localhost>]

Brook Milligan <brook%biology.nmsu.edu@localhost> writes:

>> On Aug 29, 2026, at 18:27, Greg Troxel <gdt%lexort.com@localhost> wrote:
>> 
>> Brook Milligan <brook%biology.nmsu.edu@localhost> writes:
>> 
>>> The net/sysmon package does not have an rc.d script but would seem to
>>> benefit from one.  I have drafted one up (see below) and would
>>> appreciate comments, as I am not super familiar with the nuances of
>>> rc.subr.  For example, will the value of ${sysmon_flags} automatically
>>> be inserted into the commands as written?
>> 
>> A quick read of /etc/rc.subr says yes, but put something in it and check.
>
> Just did.  If the command is overridden, then no.  It looks like all the overrides manually insert ${rc_flags} and whatnot.

There is "command" and there is "foo_cmd".  Actually set flags and run
your script and see what happens, and trace it with -x.  Have you done
that, and found that the flags are not what you expect?   It seems you
are code skimming and assuming no.    What I see in rc.subr is:

			if [ -n "$_chroot" ]; then
				_doit="\
$_env_clear_rc_vars $_env \
${_nice:+nice -n $_nice }\
chroot ${_user:+-u $_user }${_group:+-g $_group }${_groups:+-G $_groups }\
$_chroot $command $rc_flags $command_args"
			else


>>> In addition, one bikeshedding question: the package is called sysmon,
>>> but the runnable program is sysmond.  Which name should be used for
>>> the rc.d script?
>> 
>> A quick ls  of /etc/rc.d suggests that it's messy, but the predominant
>> practice is for the rc file to have the same name as the daemon.
>
> Yes, it’s messy, which is why I was asking.  There are many different patterns to choose from.

I really don't see "many".  On the system I'm writing mail on, /etc/rc.d
has 119 files that set command=.    The vast majority set it to a path
that ends in ${name}.  There are 5 exceptions, and 4 of them fail to use
the "/path/to/${name}" idiom but still set the same value.    So the
question is the relationship of $name to the filename.

  $ for i in *; do n=`egrep name= $i | awk -F= '{print $2}' | sed -e 's/"//g'`; if [ "$i" == "$n" ]; then true; else echo /$i/ /$n/; fi; done
  /CRITLOCALMOUNTED/ //
  /DAEMON/ //
  /DISKS/ //
  /LOGIN/ //
  /NETWORKING/ //
  /SERVERS/ //
  /blocklistd/ /blocklistd blocklistd.sock/
  /bootconf.sh/ /bootconf ${i##/etc/etc.}/
  /bootparams/ /bootparamd/
  /cups-browsed/ /cups_browsed # Prefix for various ${name}_XXX variables cups-browsed # File name in rc.conf.d /usr/pkg/sbin/cups-browsed # Real command that appears in ps(1) output/
  /intel-microcode/ /microcode/
  /milter-greylist/ /miltergreylist/
  /network/ /network $(kat /etc/myname) $(kat /etc/defaultdomain)/
  /nfslocking/ /statd lockd/
  /pgsql/ /pgsql /usr/pkg/bin/postgres/
  /rwho/ /rwhod/
  /spamass-milter/ /spamass_milter/
  /ttys/ /ttyflags/
  /vaultwarden/ /vaultwarden ${task}/
  /wscons/ /wscons $arg1/

Some of these have a more complicated idiom (perhaps should be cleaned
up, idk), but a tiny number have non-matching names:
  bootconf.sh
  bootparams
  cups-browsed
  intel-microcode
  milter-greylist
  nfslocking
  rwho
  spamass-milter

So matching name= and filename seems very strongly the answer.

>> 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.

> I have attached an improved version, but please let me know if
> pause/resume should be left out or you see any other issues.

I think pause/resume should be left out.  Then your script looks almost
exactly like many others, to the point where you can probably find a
bunch where the diff is just the name= line.

> #!/bin/sh
> #
> # $NetBSD$
> #
>
> # PROVIDE: sysmond
> # REQUIRE: NETWORKING
>
> $_rc_subr_loaded . /etc/rc.subr
>
> name="sysmond"
> rcvar=$name
> command=/usr/pkg/bin/${name}
> pause_cmd="${command} pause"
> reload_cmd="${command} reload"
> resume_cmd="${command} resume"
> extra_commands="pause reload resume"
>
> load_rc_config $name
> run_rc_command "$1"