>Number: 176181 >Category: bin >Synopsis: rc.subr emitting warnings for non-defined xxx_enable vars, and >errors/warnings not going to terminal >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 15 22:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Jeremy Chadwick >Release: FreeBSD 9.1-STABLE amd64 >Organization: >Environment: System: FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64 >Description: 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. >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 >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. >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"