Bug 234614 - rc framework should provide RC_SERVICE analog
Summary: rc framework should provide RC_SERVICE analog
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Kyle Evans
URL:
Keywords: dogfood, feature, needs-qa
Depends on:
Blocks: 234627
  Show dependency treegraph
 
Reported: 2019-01-04 14:35 UTC by Kyle Evans
Modified: 2019-01-16 03:32 UTC (History)
4 users (show)

See Also:
kevans: mfc-stable11+
kevans: mfc-stable12+


Attachments
git(1) diff against rc.subr (1.38 KB, patch)
2019-01-04 14:35 UTC, Kyle Evans
no flags Details | Diff
git(1) diff against rc.subr (1.38 KB, patch)
2019-01-04 18:47 UTC, Kyle Evans
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Evans freebsd_committer 2019-01-04 14:35:00 UTC
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.
Comment 1 Kyle Evans freebsd_committer 2019-01-04 14:36:42 UTC
CC'ing dteske@ and jilles@, because there's probably a better way to do this.
Comment 2 Devin Teske freebsd_committer 2019-01-04 18:37:49 UTC
$_file should be quoted, no?
Comment 3 Kyle Evans freebsd_committer 2019-01-04 18:47:30 UTC
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. =)
Comment 4 Devin Teske freebsd_committer 2019-01-05 16:31:00 UTC
LGTM. Ship it!
Comment 5 Jilles Tjoelker freebsd_committer 2019-01-05 18:06:29 UTC
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.
Comment 6 commit-hook freebsd_committer 2019-01-05 21:24:02 UTC
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
Comment 7 commit-hook freebsd_committer 2019-01-15 15:52:33 UTC
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
Comment 8 commit-hook freebsd_committer 2019-01-15 16:12:50 UTC
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
Comment 9 Kyle Evans freebsd_committer 2019-01-15 16:14:42 UTC
MFC'd to all supported branches; closing as FIXED.