From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 17:06:38 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DB51FE7 for ; Sat, 16 Feb 2013 17:06:38 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id D79482DE for ; Sat, 16 Feb 2013 17:06:37 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r1GH5xKe029853; Sat, 16 Feb 2013 12:05:59 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id YRU37942; Sat, 16 Feb 2013 12:05:58 -0500 (EST) Received: from macbook.chumby.lan (c-98-249-9-133.hsd1.va.comcast.net [98.249.9.133]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r1GH5v3u000580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Feb 2013 12:05:57 -0500 Subject: Re: some issues with /usr/sbin/service Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20130216092133.GA31449@icarus.home.lan> Date: Sat, 16 Feb 2013 12:05:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> <20130216092133.GA31449@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1283) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020209.511FBC77.0045,ss=1,re=0.000,fgs=0, ip=98.249.9.133, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: freebsd-stable@FreeBSD.org, Boris Samorodov X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:06:38 -0000 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 ??????????: >>=20 >>> 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): >>>=20 >>> 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). >>>=20 >>> Cute. Agreed -- this is unacceptable on two levels (as I see it): >>>=20 >>> 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). >>=20 >> Fully agreed here. >=20 > 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. >=20 > Gary and I have been discussing this off-list and the reason has been > found: service(8) has this code in it: >=20 > checkyesno $rcvar 2>/dev/null && echo $file >=20 > This explains why there's no warn() or err() output on the terminal -- > it's being redirected to /dev/null prior. >=20 > I do not know who maintains the rc(8) and rc.subr(8) framework, but > they've got their work cut out for them. >=20 > (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) >=20 >>> 2) These messages should not be displayed at all (i.e. lack of an >>> xxx_enable variable should imply xxx_enable=3D"no"). >>=20 >> I see this message as one more level of supervision. >>=20 >> 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). =46rom 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. >=20 > 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=3D"yes" in rc.conf'. >=20 > If not: please explain if you could what you mean, because I don't > understand. >=20 > If so: I strongly disagree with this method of approach, as what = you've > proposed is a borderline straw man argument. >=20 > 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: >=20 > To enable the xxx service, please add the following to /etc/rc.conf: > xxx_enable=3D"yes" >=20 > Of course, I don't know if this would work for packages. >=20 > The current message for is this: >=20 > WARNING: $xxx_enable is not set properly - see rc.conf(5). >=20 > 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. >=20 > Thus IMO, this is what ***should*** happen: >=20 > Definition in rc.conf Behaviour/result > ----------------------- ------------------------------------------- > myprog_enable=3D"yes" emit no warnings, service should run > myprog_enable=3D"no" emit no warnings, service should not run > myprog_enable=3D"abc123" emit a warning, service should not run > emit no warnings, service should not run I think case 4 ("") 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" =3D 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. For the base OS, I agree with your case 4; for the land of ports, I = don't think the answer is so cut and dried. That is why I think the = warning is useful: it reminds admins to look at the service in question = and make a firm decision of their own as to whether it should explicitly = be turned on or off. It is a reminder to configure the service properly = and remove ambiguity. (I also personally find the warnings a useful reminder of services that = are candidates for removal on the grounds that they appear never to have = been configured.) Cheers, Paul.=