[Bug 234614] rc framework should provide RC_SERVICE analog

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Jan 4 14:35:02 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234614

            Bug ID: 234614
           Summary: rc framework should provide RC_SERVICE analog
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs at FreeBSD.org
          Reporter: kevans at freebsd.org

Created attachment 200770
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=200770&action=edit
git(1) diff against rc.subr

Some rc scripts in ports (e.g. uwsgi, apache, openvpn) allow for 'application
profiles' that usually require the rc script to be invoked again for each
active profile. Because there's no consistent way to determine the path because
it differs between manual/service(8) invocations and /etc/rc invocations, this
leads to patterns like these:

https://svnweb.freebsd.org/ports/head/www/uwsgi/files/uwsgi.in?revision=473044&view=markup#l104
(hardcoded script path)
https://svnweb.freebsd.org/ports/head/security/openvpn/files/openvpn.in?revision=420825&view=markup#l73
(guessing a $_file or $0 based on $0 = /etc/rc)

We should provide something similar to OpenRC's RC_SERVICE that rc scripts can
consistently use to re-invoke themselves as needed, rather than having to play
guessing games.

I'm attaching a diff that approximately does ${_file-$0}, but instead sets up
an rc_service var as execution goes. It will get set initially to $0, which may
be a terrible guess if we're being executed via /etc/rc, but this guess later
gets corrected for that case in run_rc_script before the script actually gets
sourced.

Whether we're directly executing and sourcing rc.subr for the first time, or
whether rc.subr is sourcing the script, rc_service provided by rc.subr should
be correct and available in the rc script.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list