Created attachment 200770 [details] 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.
CC'ing dteske@ and jilles@, because there's probably a better way to do this.
$_file should be quoted, no?
Created attachment 200777 [details] git(1) diff against rc.subr (In reply to Devin Teske from comment #2) Ah, indeed- both $0 and $_file should likely be quoted. New version attached. =)
LGTM. Ship it!
Looks good to me, but please also add the new variable to share/man/man8/rc.subr.8. The added quotes are fine but not necessary, since assignments are not split anyway.
A commit references this bug: Author: kevans Date: Sat Jan 5 21:23:26 UTC 2019 New revision: 342792 URL: https://svnweb.freebsd.org/changeset/base/342792 Log: rc.subr: Provide rc_service variable for service scripts 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: - www/uwsgi hardcodes the script path - security/openvpn guesses either $_file or $0 based on $0 = /etc/rc Instead of forcing rc scripts to guess, provide an rc_service variable to the scripts that gets set appropriately both for direct execution or when a script is being executed via run_rc_script (e.g. /etc/rc). This is our analog of an OpenRC variable with the same name, different case (RC_SERVICE). PR: 234614 Reported by: koobs Reviewed by: dteske, jilles MFC after: 3 days Changes: head/libexec/rc/rc.subr head/share/man/man8/rc.subr.8
A commit references this bug: Author: kevans Date: Tue Jan 15 15:52:24 UTC 2019 New revision: 343045 URL: https://svnweb.freebsd.org/changeset/base/343045 Log: MFC r342792, r342805: Provide rc_service variable for rc service scripts r342792: rc.subr: Provide rc_service variable for service scripts 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: - www/uwsgi hardcodes the script path - security/openvpn guesses either $_file or $0 based on $0 = /etc/rc Instead of forcing rc scripts to guess, provide an rc_service variable to the scripts that gets set appropriately both for direct execution or when a script is being executed via run_rc_script (e.g. /etc/rc). This is our analog of an OpenRC variable with the same name, different case (RC_SERVICE). r342805: rc.subr: Fix typo Originally intended as 'in case in needs to be re-invoked', but it was later decided (by myself) that 're-invoke itself' makes it more clear that the script is expected to use this in a way. PR: 234614 Changes: _U stable/12/ stable/12/libexec/rc/rc.subr stable/12/share/man/man8/rc.subr.8
A commit references this bug: Author: kevans Date: Tue Jan 15 16:12:47 UTC 2019 New revision: 343046 URL: https://svnweb.freebsd.org/changeset/base/343046 Log: MFC r342792, r342805: Provide rc_service variable for rc service scripts r342792: rc.subr: Provide rc_service variable for service scripts 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: - www/uwsgi hardcodes the script path - security/openvpn guesses either $_file or $0 based on $0 = /etc/rc Instead of forcing rc scripts to guess, provide an rc_service variable to the scripts that gets set appropriately both for direct execution or when a script is being executed via run_rc_script (e.g. /etc/rc). This is our analog of an OpenRC variable with the same name, different case (RC_SERVICE). r342805: rc.subr: Fix typo Originally intended as 'in case in needs to be re-invoked', but it was later decided (by myself) that 're-invoke itself' makes it more clear that the script is expected to use this in a way. PR: 234614 Changes: _U stable/11/ stable/11/etc/rc.subr stable/11/share/man/man8/rc.subr.8
MFC'd to all supported branches; closing as FIXED.