Re: Adding some consistency to /etc/rc.d/*

From: Warner Losh <imp_at_bsdimp.com>
Date: Sun, 31 Aug 2025 23:25:43 UTC
On Sun, Aug 31, 2025 at 2:37 PM Dan Mahoney (Ports) <freebsd@gushi.org>
wrote:

>
>
> > On Aug 31, 2025, at 11:24, Warner Losh <imp@bsdimp.com> wrote:
> >
> > > So does rclint find just style things, or are they real problems?
> >
> > I would say files that don’t honor the traditional rc,subr enable,
> start/stop, etc are things that should be fixed.  There are many files that
> don’t have a description, that should be fixed.
> >
> > Here’s a list of what it does catch, and Chris is open to adding more,
> but this is a solid start:
> https://github.com/crees/rclint/blob/main/errors.en
> >
> > rclint doesn’t actually run the code, so it won’t spot things that, for
> example, fail to write a pid file to a directory that can’t be touched by
> the process or anything — that would require a greater framework.
> >
> > That generally sounds like useful information on producing sane fixes...
> That's likely worth the effort. If it were to just be pedantic to some
> arbitrary standard that doesn't increase the resilience, reliability, etc
> of the services. Is that a tool that could also be used to screen new rc.d
> files?
>
> Yes.  As mentioned previously, I only discovered it while I was writing
> some startup stuff for ISC (for our own daemon scripts, like those that
> pull routes if BIND isn’t running), and couldn’t find a “perfect example”
> and this was what I found.  It’s “something”.
>
> It’s written by Chris Rees (who is another ports committer).  I’m sure if
> there were other things that felt useful, he’d take the feedback, but this
> feels like a good start.
>
> Here was a pull request for ntpd.  It mostly involved removing quotes from
> variable names, formatting functions consistently, and reordering a few
> functions at the top:
> https://github.com/freebsd/freebsd-src/compare/main...thegushi:freebsd-src:rclint-ntpd


I'll take a look at it.

I will admit that this one just feels like cosmetic changes, but it was the
> first one I did just to see how hard it would be.  As ntpd is a well known
> service, used by lots of people, that likely gets a lot of love — this
> won’t be the case for every service.  I could absolutely make this my
> morning sudoku puzzle for a few months :)
>
> If you want to see a way less consistent service, look at “serial”.(1)
>
> -Dan
>
> (1)  (Also, I know the author of that file is a long time core-team member
> who was well liked and is now deceased, but does that mean his copyright
> should sit in the file in perpetuity as a memoriam, or that at some point,
> the code is simply owned by the project?)
>

He, or his estate, owns the copyright until it expires, so it's appropriate
to keep it in the file.... so long as it contains his code, and that code
is important to the file. That's how copyrights work, and the project can't
do what you describe unless his code is replaced (but then it would be a
new person that owns the copyright). While the file remains in large part
written by Andrey Chernov, David O'Brien, Ruslan Ermilov, Marcel Moolenaar
and possibly Bruce Evans also have written parts of the file...  I just
removed the bits that maybe Bruce would have a copyright for (sorry Bruce),
since I just pushed a change that removed the cyclades and digiboard
references since those drivers were removed in 2016. Having said all that,
do we even need this file anymore? Can we also GC serial mouse support from
it, since that's not been relevant in 25 years... And many of the things it
mentions are gone:

#       dtrwait 300 drainwait `sysctl -n kern.drainwait`

That's now kern.tty_drainwait. and dtrwait is dead code. There's an ioctl
for it TIOCMSDTRWAIT that's only defined, but never referenced anywhere. It
was removed in the tty mpsafe work that was done for FreeBSD 8...  So
clearly some additional cleanup could be made.

Warner


> Side Note: The github workflow has a lot of things to say about the
> wording of commit messages, use of voice, etc, but I don’t think there’s a
> document I’ve found for what should be used for service names in rc.d.
>