From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 18:24:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 063EC37B; Sat, 16 Feb 2013 18:24:52 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8967E6; Sat, 16 Feb 2013 18:24:51 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so5897021ieb.23 for ; Sat, 16 Feb 2013 10:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=KaNkbkvdryqXPt/D7I3cIlINtnwBk2yV6K8+5w33rgE=; b=TryLK6rJz9zeSwqA+FXE8RxFDY6pwxpEpOpq4MS6fKKpxv7Yqcc4dTzodpy8siidbJ E585XiOAHRBRJkDhkXhlhGgOOzpZxNvYyXub+iV0vjyd46PPZdG2YULIwn9tL18fBy/1 gCTjrC3WSWtUr4MV7cX8079UgxRvcoAr2lpchv6YE5I8TBEBudWPhXcpKjSzqXUDJKos IogJ6TVOpEiEbuTCOWaurguevAh7eJzOcFx2lFiRwTQ6F3ePnm/gUfRMnCyqDONlAeTr /JtE31EDlIFgpDYnizJ8brYhrwSw/CuJM0Gmedhp5WiaOd1xbKToXtUpmu4kiuDUTjem h47Q== X-Received: by 10.50.13.175 with SMTP id i15mr4223440igc.75.1361039091202; Sat, 16 Feb 2013 10:24:51 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.63.12 with HTTP; Sat, 16 Feb 2013 10:24:20 -0800 (PST) In-Reply-To: <20130216180859.GF85777@in-addr.com> 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> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> <20130216180859.GF85777@in-addr.com> From: Chris Rees Date: Sat, 16 Feb 2013 18:24:20 +0000 X-Google-Sender-Auth: QwuXglDvBmeLH9mY7ASPkryKYp0 Message-ID: Subject: Re: some issues with /usr/sbin/service To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick , FreeBSD , 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 18:24:52 -0000 On 16 February 2013 18:08, Gary Palmer wrote: > On Sat, Feb 16, 2013 at 05:38:56PM +0000, Chris Rees wrote: >> On 16 February 2013 17:05, Paul Mather 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 fi= nd >> >>>> 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_e= nable is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_ena= ble is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_ena= ble is not set properly - see rc.conf(5). >> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcachecle= an_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 sourc= e >> >> 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=3D"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 u= p >> >>> 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 nee= d >> >> to set xxx_enable=3D"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=3D"yes" >> >> >> >> Of course, I don't know if this would work for packages. >> >> >> >> The current message for is this: >> >> >> >> WARNING: $xxx_enable is not set properly - see rc.conf(5). >> >> >> >> The message is entirely misleading for this specific situation; it is= n't >> >> "reminding" an administrator -- if anything it's confusing them (thre= ad >> >> 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=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 O= S 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 wil= l 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. >> >> With few exceptions, it should be considered a rule that ports rc >> scripts contain: >> >> : ${xxx_enable=3Dno} >> >> to avoid this. If you see any ports that don't define the _enable >> variable at all, they are wrong and need fixing. > > Except the 'service' command doesn't parse the individual ports rc.d > script so the default is never found. It relies purely on rc.conf and > rc.conf.local settings. > > So no matter if the port has > > : ${xxx_enable=3Dno} > > or not, 'service -e' will still spit out the warnings > > Not loading the individual ports files is probably done for two reasons > I can think of - performance, and safety (in case the rc.d file is bad > for some reason). However it leads to these rather irritating > warnings, especially when you find them later and you don't know what > you did to cause them. > > I was away to suggest that having /usr/local/etc/rc.conf.d would help > as ports could then specify their defaults safely without having to do > file rewrites, however that appears to be only looked at in > load_rc_config(), and 'service -e' bypasses that as well by doing > > load_rc_config 'XXX' > > so only /usr/local/etc/rc.conf.d/xxx would be looked at. Yes, OK. A variation on Alfred's checkyes patch is at [1]. I have not made it into a function deliberately because this is already rc idiom as used in other rc scripts where a warning is not necessary, and also because it is very rarely the right thing to do (i.e. it would be tempting to overuse it if it were a function). Chris [1] http://www.bayofrum.net/~crees/patches/service-no-logging.diff