ports/90070: [MAINTAINER] mail/rabl_server: per sougb request, use "new style" RC script

[Doug Barton]

Thanks for including me on this thread, I'm really glad to see some
interest/progress here.

Ion-Mihai Tetcu wrote:
> On Fri, 09 Dec 2005 14:38:43 +0100
> Pav Lucistnik <pav at FreeBSD.org> wrote:
> 
> [ .. dougb's change is not transparent for ports that USE_RC_SUBR .. ]
> 
>>>>>> This is absolutely something that must be fixed in the
>>>>>> infrastructure, not in every port over and over again.

Agreed, and I also agree with Pav's perspective that our interests are best
served by doing this right the first time.

>>>>> My point exactly. And, as I've said, I'm willing to work on
>>>>> this; I could (manually) check the USE_RC_SUBR ports over the
>>>>> weekend to see what kind of rc script they're using. But I need
>>>>> to know which way to go: renaming non-RCng scripts to *.sh,
>>>>> etc., or I could try to convert them to RCmng (but this should
>>>>> be done but maintainers, as they know better what to REQUIRE,
>>>>> etc.)

To give you an idea of what we're facing; roughly 650 ports install startup
scripts, roughly 350 of them have been converted to use the new rc.d style
(we don't refer to it as rcng anymore), roughly 322 of those have
USE_RC_SUBR in the Makefile, and roughly 151 of those have the name of the
script as the value of the variable (the rest have some variant of
yes/YES/true, etc.).

In an ideal world, it would be great if all of the ports could be converted
to the new style, but I've been very careful not to ask for that, as I
realize it's a big chunk of work, and I'm not in a position at the moment to
help with it. I would be glad to provide what assistance I can however. One
useful idea that I'd like to pass on that Brooks suggested is that rather
than try to convert very complex boot scripts, it would be easier to install
that boot script in PREFIX/libexec, and have the rc.d-style script call that.

In terms of the actual conversion, if you wanted to ensure that the scripts
run as close as possible to their current place in the order, you could use
# REQUIRE: localpkg
# BEFORE:  securelevel

Otherwise, most scripts just require LOGIN, which should work fine in most
cases. The rcorder(8) page contains all the information you need to create
simple rc.d scripts, feel free to ask on freebsd-rc@ if you need more help
than that. FYI, the current rcorder is up at
http://people.freebsd.org/~dougb/rcorder.all, although it's easy enough to
reproduce if you follow what's in rc. I've attached a simple example of a
startup script. You can actually make this even simpler in certain
circumstances. See rcorder(8) and /etc/rc.d/usbd for an example.

Oh, one more thing, it is no longer necessary to include
KEYWORD: FreeBSD. It would be good however if scripts that start services
include the KEYWORD: shutdown, and a stop_cmd that kills the service.

>>>> Is it a good thing to modify USE_RC_SUBR inside bsd.port.mk to
>>>> install without .sh suffix if ${OSVERSION} > 7000xx and be done
>>>> with it?

Agree. Also, this will make it a LOT easier when we MFC this change, which
I'll be ready for very soon.

>>> I think so, but we must check that (1) at least all ports that
>>> USE_RC_SUBR have RCng scripts and (2) no port relies on .sh adding;
>>> 1 and 2 are somehow the same thing, as 2 hurts only if 1 is false.
>>>
>>> In the end we should have only new-style RCng scripts
>>> (files/rc_script.in) whit ports setting USE_RC_SUBR= rc_script.in,
>>> installed as such on HEAD (and sometime on 6-STABLE) and .sh added
>>> for older OSVERSIONs.

Agreed in principle ... in the long term we'd like to have all boot scripts
installed as just foo, instead of foo.sh. That way we could return to
sourcing scripts that end in .sh into the shell, in case someone is
depending on that behavior.

>> Other way around, leave USE_RC_SUBR=skript.sh and files/skript.sh.in,
>> to avoid repo churn, and strip .sh when installing on newer
>> OSVERSIONs.

I'll leave that implementation detail up to y'all.

> And end up with an other "historical" rule. (Q: Why are rc scripts
> named .sh.in and installed w/o .sh ? A: In the past scripts used to be
> sourced in a sub-shell if they had .sh .... ). And not all scripts are
> apt to be installed w/o .sh (I didn't check and I don't know if they
> would run and rcorder and fiends don't choke on them since they have
> no keywords, maybe doug can tell us).

The way that code works right now:
1. rcorder is run up to mountcritremote with only the scripts in /etc/rc.d
2. rc stops at that point, runs a function that finds scripts in
local_startup that include the PROVIDE string
3. rc runs rcorder again, including any new scripts from local_startup, and
ignoring everything up to mountcritremote
4. All of the scripts run as part of rcorder are currently being run in a
subshell, except for those that match the pattern /etc/rc.d/*.sh. This will
remain true for the foreseeable future, until things are much more settled.
5. When /etc/rc.d/localpkg is run as part of rcorder, it goes through
local_startup looking for scripts that do NOT contain the PROVIDE string,
and runs those in a subshell

The two things that are going to change are that the default divider between
early and late will be changed to mountcritlocal, and that divider will be
configurable. That change should go in today, but shouldn't break anything.
The other thing that we'd like to change down the road, as I said above, is
that we'd like to be able to source all scripts that end in .sh into the
shell again, but as mentioned above that change is a ways down the road.

> Hmm, since we have to check the scripts anyway, what if I convert any
> non-RCng for ports that USE_RC_SUBR ? This is on the todo list anyway.
> If something gets broken (== not really broken, but started to late or
> something like that) in the process at least the maintainers will have
> to fix them (as apposed to the current situation when we still have
> non-RCng scripts).

Given that prior to the change going into HEAD, _all_ of those scripts were
run from /etc/rc.d/localpkg, it should be trivial (as above) to at least
make things no worse than they were, and correspondingly put a tool in the
hands of port authors who need better control over ordering. There is
already one person who has sent a very well thought out message to
freebsd-rc@ asking about this, and is excited about how he's going to be
able to move forward.

I also read Pav's message, and the proposed patch looks good, modulo the
issue I mentioned above that about 170 of the ports that have USE_RC_SUBR do
not have the name of the port as the value of the variable.

I know that this post is long, and if you've gotten this far, thanks! If
there is anything else I can do to help, please let me know.


Doug

-- 

     This .signature sanitized for your protection


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testnewrc
URL: <http://lists.freebsd.org/pipermail/freebsd-ports-bugs/attachments/20051209/3e3ff1b3/attachment.ksh>