Bug 185429

Summary: [rc.subr] ${name}_chroot does not work when there's a custom rc "start_cmd"
Product: Base System Reporter: dreamcat4
Component: confAssignee: freebsd-bugs mailing list <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 9.1-RELEASE   
Hardware: Any   
OS: Any   

Description dreamcat4 2014-01-02 23:30:01 UTC
There is a bug in /etc/rc.subr

the bug is:
if [ there's a custom ${XXX_cmd}, ]
  E.g. an rc "start_cmd", "stop_cmd".

then 
  "${name}_chroot" does not work.

Documentation:
man -Pcat rc.subr | grep -5 -i chroot

 ${name}_chroot
   Directory to chroot(8) to before running command.
   Only supported after /usr is mounted.


It happens at these begin/end points:

https://gitorious.org/freebsd/freebsd/source/1e0e806b8822c4570e09508df054f82f9a47ce0e:etc/rc.subr#L684-739

If you look in rc.subr at those lines ^^ control is obviously never getting to the part where it kicks of the chroot case... which only happens in case start).

There may be more bugs nearby, and for the same reason.
Will fix / wont fix ?

Many thanks.

Fix: 

need to edit the file "/etc/rc.subr" around these lines:

https://gitorious.org/freebsd/freebsd/source/1e0e806b8822c4570e09508df054f82f9a47ce0e:etc/rc.subr#L684-739

So that ${name}_chroot is checked for, even at the top where it says:

"# if there's a custom ${XXX_cmd},"
...
How-To-Repeat: for any rc.d service that sets "start_cmd" at the top of its rc.d script

1) set "${name}_chroot=/path/to/chroot" in rc.conf
2) set "name_enable=YES" in rc.conf
3) start that rc.d service
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-01-06 00:12:40 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-rc

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:59 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped