Bug 185429 - [rc.subr] ${name}_chroot does not work when there's a custom rc "start_cmd"
Summary: [rc.subr] ${name}_chroot does not work when there's a custom rc "start_cmd"
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 9.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2014-01-02 23:30 UTC by dreamcat4
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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".

  "${name}_chroot" does not work.

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

   Directory to chroot(8) to before running command.
   Only supported after /usr is mounted.

It happens at these begin/end points:


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.


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


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