On 16 February 2013 17:05, Paul Mather <[email protected]> wrote:
> On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote:
>
>> On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote:
>>> 16.02.2013 01:32, Jeremy Chadwick ??????????:
>>>
>>>> Follow up -- I read Alfred's most recent mail. Lo and behold, I find
>>>> this in /var/log/messages (but such did not come to my terminal):
>>>>
>>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable
>>>> is not set properly - see rc.conf(5).
>>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is
>>>> not set properly - see rc.conf(5).
>>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is
>>>> not set properly - see rc.conf(5).
>>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING:
>>>> $htcacheclean_enable is not set properly - see rc.conf(5).
>>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable
>>>> is not set properly - see rc.conf(5).
>>>>
>>>> Cute. Agreed -- this is unacceptable on two levels (as I see it):
>>>>
>>>> 1) These messages should be going to stdout or stderr in some way, so
>>>> honestly logger(8) should be called with the "-s" flag (IMO).
>>>
>>> Fully agreed here.
>>
>> It turns out logger -s has no effect, just like how the echo 1>&2
>> statements in warn() and err() have no effect either (these should be
>> outputting the warnings in question to stderr) -- see rc.subr's source
>> for what I'm referring to.
>>
>> Gary and I have been discussing this off-list and the reason has been
>> found: service(8) has this code in it:
>>
>> checkyesno $rcvar 2>/dev/null && echo $file
>>
>> This explains why there's no warn() or err() output on the terminal --
>> it's being redirected to /dev/null prior.
>>
>> I do not know who maintains the rc(8) and rc.subr(8) framework, but
>> they've got their work cut out for them.
>>
>> (Note: the echo statements in warn() and err() could be replaced with
>> "logger -s" as I said; this would allow the "echo 1>&2" to be removed)
>>
>>>> 2) These messages should not be displayed at all (i.e. lack of an
>>>> xxx_enable variable should imply xxx_enable="no").
>>>
>>> I see this message as one more level of supervision.
>>>
>>> If undefined at /etc/make.conf the value of xxx_enable is "no" from the
>>> system's POV (i.e. the service is not strarted). From the
>>> admininstrators's POV the port was installed BUT is not used. It's up
>>> to admininstrator whether it's OK or not -- just let him remind.
>>
>> I believe the point you're trying to make is that the warning in
>> question should 'act as a reminder to the administrator that they need
>> to set xxx_enable="yes" in rc.conf'.
>>
>> If not: please explain if you could what you mean, because I don't
>> understand.
>>
>> If so: I strongly disagree with this method of approach, as what you've
>> proposed is a borderline straw man argument.
>>
>> Reminding the admin to set xxx_enable is presently done inside most
>> ports' pkg-message. IMO, this should really be done inside bsd.port.mk
>> when USE_RC_SUBR is used, emitting a message during install that says
>> something like:
>>
>> To enable the xxx service, please add the following to /etc/rc.conf:
>> xxx_enable="yes"
>>
>> Of course, I don't know if this would work for packages.
>>
>> The current message for <missing xxx_enable in rc.conf> is this:
>>
>> WARNING: $xxx_enable is not set properly - see rc.conf(5).
>>
>> The message is entirely misleading for this specific situation; it isn't
>> "reminding" an administrator -- if anything it's confusing them (thread
>> is case in point). If we're going to cater to ignorance, then the
>> message should reflect the situation.
>>
>> Thus IMO, this is what ***should*** happen:
>>
>> Definition in rc.conf Behaviour/result
>> ----------------------- -------------------------------------------
>> myprog_enable="yes" emit no warnings, service should run
>> myprog_enable="no" emit no warnings, service should not run
>> myprog_enable="abc123" emit a warning, service should not run
>> <no definition> emit no warnings, service should not run
>
>
> I think case 4 ("<no definition>") is a case where a warning should be
> emitted because it is arguably not immediately apparent what will actually
> happen if no definition is present. In the case of services in the base OS
> it is well-defined: every service should have an explicit default in
> /etc/defaults/rc.conf that you can easily consult to know definitively what
> will happen with that service. (If it doesn't, that is a bug, IMHO.)
>
> For ports, the case is not so clear. There is a general trend for the port
> rc.d script to default its respective xxx_enable explicitly to "NO". But it
> is not a universal rule that "no definition" = default to "NO". The
> net/avahi-app port, for example, doesn't default to "NO" if xxx_enable is not
> set: it defaults to whatever the gnome_enable setting is defined to be.
With few exceptions, it should be considered a rule that ports rc
scripts contain:
: ${xxx_enable=no}
to avoid this. If you see any ports that don't define the _enable
variable at all, they are wrong and need fixing.
Chris
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
