Bug 176181 - [rc.subr] rc.subr emitting warnings for non-defined xxx_enable vars, and errors/warnings not going to terminal
Summary: [rc.subr] rc.subr emitting warnings for non-defined xxx_enable vars, and erro...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 9.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-15 22:10 UTC by Jeremy Chadwick
Modified: 2017-12-31 22:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Chadwick 2013-02-15 22:10:00 UTC
	The following discussion has taken place on freebsd-stable:

	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072303.html
	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072304.html
	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072317.html
	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072318.html
	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072319.html
	http://lists.freebsd.org/pipermail/freebsd-stable/2013-February/072320.html

	There are two issues as I see them:


	1. Lack of a defined xxx_enable variable in rc.conf(5) (regardless
	of the value) results in warn() being called.  Ex:

	WARNING: $svnserve_enable is not set properly - see rc.conf(5).

	A lack of definition of xxx_enable variable should be treated as
	the same as xxx_enable="no" (i.e. the service is disabled) and
	should not emit a warning.


	2. When using service(8), the warn() calls are not making it
	to the user's terminal -- they only end up in /var/log/messages.

	Looking at rc.subr(8), it appears the echo statements in err()
	and warn() are not making it to the user's terminal.  I tried
	using "logger -s" and it made no difference -- it's as if some
	part of the rc.subr infrastructure is redirecting stdout and
	stderr to /dev/null way before the echo statements.

Fix: 

The patch provided by Alfred Bartsch does address issue #1, however I
	feel that (effectively) changing checkyesno() to remove the warn() is
	not the right solution.  I believe it would be wiser to handle the
	situation through, for example, an "if [ -n $xxx_enable ]" test of
	some kind.
How-To-Repeat: 	* Install a port that uses rc.d in some way
	* Make sure there is no xxx_enable variable set for it in /etc/rc.conf
	* Run "service -e"
	* Check /var/log/messages
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-02-24 23:34:53 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-rc

Reclassify.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:07 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