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: b...@freebsd.org
Reporter: kev...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
