Scripts in /usr/local/etc/rc.d/*.sh are no longer started on boot

[pdf]

As of 1.15.7, these scripts no longer appear to be executed on boot, though they still appear to be killed on shutdown.

I really wish there was a way to start/stop the standard rc scripts, but that's a whole other issue.

[fichtner]

I think it has always been this way? Are you referring to a particular script?

[pdf]

There used to be a mechanism that would run scripts that end in .sh that are placed there, specifically because the rc system is intentionally broken in *sense, so that it's possible for users to run custom code/daemons.

[fichtner]

I wouldn't call it broken. It just doesn't fit a dual use case as a contained product merged with a plain FreeBSD type server. We've worked hard on getting rid of custom hooks and execute-this-custom-blob type scripting that makes for tomorrows security nightmares. The new package system will support this in a cleaner way, you won't even have to deal with GUI if you don't want to and all the tools to build the package will be freely available so you won't have to push your code upstream (I reckon it is internal code). Does that sound acceptable to you?

[pdf]

We're discussing a couple of different things here. The subject of this issue is that prior to 1.15.7, the existing mechanism inherited from pfSense of running addtional code on boot - placing a .sh file in /usr/local/etc/rc.d/ - worked, but from 1.15.7 of OPNsense, this does not work, and now there is no mechanism other than modifying files that will be overwritten by upgrades.

On the topic of whether 'breaking' (I don't think the term is incorrect - the standard boot process was hacked to disable it) the standard FreeBSD RC system was a good design decision, that's a more complex question. If I was designing something like this from scratch, I'd try really hard to integrate with the existing system before I discarded it, because you get the benefit of having edge-cases solved once rather than multiple times, easy transferal of skills, and lower cost to add new features, at the expense of some maintenance overhead and a slight reduction in flexibility. The way the FreeBSD rc system works via variables, it would have been pretty easy to integrate using some sourced config files generated from templates. None of that is related to this particular issue though.

On whether the packaging system will be adequate or sensible for all scenarios, that's impossible to say at this stage, with the information available, but I don't see how it would be in any way advantageous for security to stop people running their own code via a script, but provide some more convoluted method for them to run that same code.

[fichtner]

Yes, please help us design such a system. You will most likely end up with something that you'll be happy with. :)

[pdf]

So, I'm still not clear - was this functionality removed on purpose?

[AdSchellevis]

The location /usr/local/etc/rc.d/ is used by all the standard scripts included in all the packages, so enabling that might kick to much in at the moment. I agree it could be practical to include your own rc scripts (for more advanced users/system integrators). I will mark this one as feature request for the moment, as soon as we find the time to implement something we will pick it up. For our new components (using the new framework) we probably have to change this area on some degree anyhow.

[pdf]

I think there's still confusion here - this was a feature inherited from pfSense, and worked until 1.5.17, where it was broken.

[AdSchellevis]

Your probably right, there might be confusion over here. I was under the impression that the rc.d scripts weren't used by the custom rc scripting. Where all the scripts started before? or only some? In my install there are quite some scripts in there placed by the standard packages which (probably) shouldn't be started by default.

[pdf]

Only scripts placed there, ending in .sh would be started. None of the standard rc.d scripts end in .sh, so you're correct in thinking that they aren't started by the custom rc stuff. Didn't seem like a particularly sensible way of doing things, but it was the only way of starting non-core stuff that I could find for pfSense.

[AdSchellevis]

I haven't found the old feature yet in the sources, but I do think we should replace it for something more sensible. Let's keep this issue open for now, I will look into it further.

[AdSchellevis]

Found it, the old option to start the scripts was placed inside the package code we removed (rc.start_packages). I will keep this issue open and think of an alternative.

[pdf]

Thanks for following up @AdSchellevis

[AdSchellevis]

The next version will include a new rc.d hook into the base system, see f290b78 and some additional info in the forum https://forum.opnsense.org/index.php?topic=274.msg1020#msg1020

Is it ok to close this issue?

[pdf]

Looks like this ought to work for my use-case. Will this also result stop being issued on shutdown? Just thinking that some daemons may have custom safe shutdown handling in their rc scripts.

EDIT: Also, the old code that kills scripts started via the old method was still around in 15.1.8.2, even though the startup code was removed.

[AdSchellevis]

I kind of forgot and was just looking at it :-) I will make sure the stop is also being issued (or stays in place if it already is decent)

[AdSchellevis]

The normal shutdown sequence should kind of shutdown the daemons, but I rather make the behaviour explicit and make sure the normal stop operation is used. d6ae716 contains the fix.
I'll close the issue.

[zbrozek]

It looks like this functionality has evaporated in the intervening years. Is there a new preferred way to start a script at boot? In my case I want to launch iperf3 daemons on several ports at boot.

[fichtner]

Just open a proper bug report and avoid unfounded generalisation on tickets from years ago that fixed a particular bug. It is of no use to anyone.