>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"

Reply via email to