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

> 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 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?)

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.