Re: Issues in rc scripts (PROVIDES != name != script name)

On 02/07/2024 14:56, Alexander Leidinger wrote:
> Hi,
> 
> I'm investigating some issues with the new service jails feature. It 
> comes down to the naming of the rc scripts. We have scripts where we 
> have a mismatch between the setting of the name variable inside the 
> script and the filename. This mail is to get some input on the best way 
> forward.
> 
> The rc scripting docu 
> (https://docs.freebsd.org/en/articles/rc-scripting/) doesn't require 
> that the name of the rc script is the same as the name in the name 
> variable inside the script, but it suggests it:
> ---snip---
> Now it is the right time to choose a unique name for our script once and 
> for all. We will use it in a number of places while developing the 
> script. For a start, let us give the same name to the script file, too.
> ---snip---
> 
> The new service jails framework 
> (https://docs.freebsd.org/en/books/handbook/jails/#service-jails) makes 
> use of this (it uses the name variable to execute the script inside a 
> newly created jail).
> 
> I wrote a little script which parses the script in the ports collection 
> and it found 255 scripts with issues (out of 3361 scripts -> ~7.6% -- 
> there are some false positives, to the percentage may even be smaller). 
> For 124 of those the variable name uses an underscore and the script 
> name uses a hyphen instead (this is where I noticed issues with the 
> service jails).
> 
> While I was at it, I also checked for a mismatch between the name 
> variable and the PROVIDES meta-comment inside. Strictly speaking this is 
> not necessary, and there may even be cases where it is a feature that it 
> is not the same, but those errors are part of the 255 issues.
> 
> Examples:

[..]

> Generally I would say for various reasons (not only for service jails, 
> but also for the benefit of other tools which may want to make use of 
> this info to make it more easy to match meta-data with/in rc scripts) we 
> should make this uniform where possible. So renaming all the xxx-xxx.in 
> to xxx_xxx.in and have the PROVIDES match what is in the name variable.
> 
> There are some high-profile ports affected:

[..]

> This will not change the autostart at boot (the rc variables stay the 
> same, it is the filenames which would change), but if someone has some 
> scripts to automate some stuff (ansible/puppet/chef/cfengine/plain 
> shell/...) there may be some surprises.
> 
> I would like to:
>   - rename the scripts and fix the PROVIDES part (with a suitable 
> UPDATING entry)
>   - change the rc docu to strongly advise that the script name matches 
> the content of the name variable during runtime (allows the instancing 
> and the %%PORTNAME%% stuff) with some example where it matters
> 
> What's the generic feeling here about this?

100% agree on this (where it is possible to fix it). I remember being 
bitten by this in 2010 when I tried to add support for cpuset into 
rc.subr (commited 13 years later!)
https://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001814.html

There was a problem with rc.d/bgfsck - hyphen in the $name

name="background-fsck"
rcvar="background_fsck"

Which is now fixed to an underscore, so I agree that this should be 
fixed for all ports rc scripts too. A hyphen in the value of the 
variable name can break anything at any time.

Kind regards
Miroslav Lachman