NetBSD Problem Report #48555

From www@NetBSD.org  Mon Jan 27 14:02:43 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EFE6DA6482
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 27 Jan 2014 14:02:42 +0000 (UTC)
Message-Id: <20140127140241.6DEC4A6488@mollari.NetBSD.org>
Date: Mon, 27 Jan 2014 14:02:41 +0000 (UTC)
From: rnestor@tx.rr.com
Reply-To: rnestor@tx.rr.com
To: gnats-bugs@NetBSD.org
Subject: rc.conf handling of program=yes/no
X-Send-Pr-Version: www-1.0

>Number:         48555
>Category:       pkg
>Synopsis:       security/dirmngr rc script broken
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 27 14:05:00 +0000 2014
>Last-Modified:  Thu Oct 16 04:55:00 +0000 2014
>Originator:     Bob Nestor
>Release:        NetBSD 6.1.3
>Organization:
>Environment:
NetBSD dumbo.home.net 6.1.3 NetBSD 6.1.3 (GENERIC) i386
>Description:
The man page on rc.conf indicates that a program/package may be started on boot by including the line "program=YES" in rc.conf.  It also indicates that the program may be disabled on boot by changing the line to "program=NO'.

For any line in the rc.conf file of the form "program=NO" an error is produced on system shutdown with the text "[NO not found".

Commenting out the "program" line(s) in rc.conf produces boot errors that "program is not properly configured".

These are minor errors that have been present in earlier releases as well.
>How-To-Repeat:
Try including "program=NO" and "#program=YES" or "#program=NO" lines in rc.conf and observe the bootup or shutdown messages produced.
>Fix:
unknown

>Release-Note:

>Audit-Trail:
From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 16:46:47 +0200

 On Mon, 27 Jan 2014, rnestor@tx.rr.com wrote:
 > The man page on rc.conf indicates that a program/package may be 
 > started on boot by including the line "program=YES" in rc.conf. 
 > It also indicates that the program may be disabled on boot by 
 > changing the line to "program=NO'.

 Please use reasonable length lines; don't represent an entire 
 paragraph as a single very long line.  I have re-wrapped your text 
 to something less than 80 characters per line.

 > For any line in the rc.conf file of the form "program=NO" an 
 > error is produced on system shutdown with the text "[NO not 
 > found".

 I could understand an error like that for a variable that might be 
 used as the name of a program instead of as a yes/no switch, but 
 surely not for all variables, and the square bracket in the error 
 message is also hard to explain.

 Please report the exact error message, and the exact line in 
 /etc/rc.conf.  The name of the variable is important, so please 
 don't change it to "program".

 --apb (Alan Barrett)

From: Bob Nestor <rnestor@tx.rr.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 09:04:19 -0600

 Well, I don't want to come off argumentative here, but I
 used the web interface to gnats to file this report.
 It doesn't indicate that I have to wrap the lines in
 the report.  Maybe this should be filed as a bug
 in the gnats web interface.

 As for "program=", ok if that was to difficult to
 understand.  Try using "dirmngr=NO" and then
 executing "/etc/rc.d/dirmngr restart".  It will
 attempt to stop dirmngr first and report an
 error. You may need to start dirmngr first
 using a "dirmngr=YES" line.

 Or try setting the line to "#dirmngr=YES" and
 rebooting the system.  The rc.log will indicate
 an improperly configured dirmngr.

 And I hope this lines are short enough for
 viewing.

 On Jan 27, 2014, at 8:50 AM, Alan Barrett wrote:

 > The following reply was made to PR misc/48555; it has been noted by GNATS.
 > 
 > From: Alan Barrett <apb@cequrux.com>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: misc/48555: rc.conf handling of program=yes/no
 > Date: Mon, 27 Jan 2014 16:46:47 +0200
 > 
 > On Mon, 27 Jan 2014, rnestor@tx.rr.com wrote:
 >> The man page on rc.conf indicates that a program/package may be 
 >> started on boot by including the line "program=YES" in rc.conf. 
 >> It also indicates that the program may be disabled on boot by 
 >> changing the line to "program=NO'.
 > 
 > Please use reasonable length lines; don't represent an entire 
 > paragraph as a single very long line.  I have re-wrapped your text 
 > to something less than 80 characters per line.
 > 
 >> For any line in the rc.conf file of the form "program=NO" an 
 >> error is produced on system shutdown with the text "[NO not 
 >> found".
 > 
 > I could understand an error like that for a variable that might be 
 > used as the name of a program instead of as a yes/no switch, but 
 > surely not for all variables, and the square bracket in the error 
 > message is also hard to explain.
 > 
 > Please report the exact error message, and the exact line in 
 > /etc/rc.conf.  The name of the variable is important, so please 
 > don't change it to "program".
 > 
 > --apb (Alan Barrett)
 > 

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 16:09:58 +0100

 On Mon, Jan 27, 2014 at 03:05:01PM +0000, Bob Nestor wrote:

 >  As for "program=", ok if that was to difficult to
 >  understand.  Try using "dirmngr=NO" and then
 >  executing "/etc/rc.d/dirmngr restart".

 Where does "dirmngr" come from? It is not a system supplied script.
 There probably is a bug in that script.

 >  Or try setting the line to "#dirmngr=YES" and
 >  rebooting the system.  The rc.log will indicate
 >  an improperly configured dirmngr.

 That is expected - if you have added a custom (or pkgsrc supplied) script
 it will have no proper default (/etc/defaults/rc.conf), so you need to
 set it to YES or NO explicitly.

 Martin

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 17:48:13 +0200

 On Mon, 27 Jan 2014, Bob Nestor wrote:
 > Well, I don't want to come off argumentative here, but I
 > used the web interface to gnats to file this report.
 > It doesn't indicate that I have to wrap the lines in
 > the report.  Maybe this should be filed as a bug
 > in the gnats web interface.

 That sounds like a bug in the web interface.  Sorry I complained 
 about something that's not your fault.

 > As for "program=", ok if that was to difficult to
 > understand.  Try using "dirmngr=NO" and then
 > executing "/etc/rc.d/dirmngr restart".  It will
 > attempt to stop dirmngr first and report an
 > error. You may need to start dirmngr first
 > using a "dirmngr=YES" line.

 Is this dirmngr from pkgsrc/security/dirmngr?  Try changing 
 line 56 of /etc/rc.d/dirmngr from

 	eval `${dirmngr_command} ${rc_flags}`

 to

 	eval "${dirmngr_command} ${rc_flags}"

 (double quotes instead of backticks).  I have not tested this, but 
 it's possible that it will help.

 --apb (Alan Barrett)

From: Bob Nestor <rnestor@tx.rr.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 10:20:19 -0600

 This was a clean install of 6.1.3 with packages from the 6.1 repository.
 I believe dirmngr is installed as a dependency on kde-3.5.10, although
 I'm not sure why since kde seems happy without dirmngr running. All
 the startup files were copied from the examples rc.d directory without
 any modifications.

 I see this problem on many other packages as well, including
 #postfix=YES
 ipfilter=NO
 ipnat=No
 etc.

 That was my reason for originally reporting the problem
 as "program=YES/NO" rather than being specific as to which
 program packages were seeing the error.  I was afraid the
 analysis would zero in on a problem in a specific package
 when it MAY be a more generic problem with the rc scripts
 themselves.

 On Jan 27, 2014, at 9:50 AM, Alan Barrett wrote:

 > The following reply was made to PR misc/48555; it has been noted by GNATS.
 > 
 > From: Alan Barrett <apb@cequrux.com>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: misc/48555: rc.conf handling of program=yes/no
 > Date: Mon, 27 Jan 2014 17:48:13 +0200
 > 
 > On Mon, 27 Jan 2014, Bob Nestor wrote:
 >> Well, I don't want to come off argumentative here, but I
 >> used the web interface to gnats to file this report.
 >> It doesn't indicate that I have to wrap the lines in
 >> the report.  Maybe this should be filed as a bug
 >> in the gnats web interface.
 > 
 > That sounds like a bug in the web interface.  Sorry I complained 
 > about something that's not your fault.
 > 
 >> As for "program=", ok if that was to difficult to
 >> understand.  Try using "dirmngr=NO" and then
 >> executing "/etc/rc.d/dirmngr restart".  It will
 >> attempt to stop dirmngr first and report an
 >> error. You may need to start dirmngr first
 >> using a "dirmngr=YES" line.
 > 
 > Is this dirmngr from pkgsrc/security/dirmngr?  Try changing 
 > line 56 of /etc/rc.d/dirmngr from
 > 
 > 	eval `${dirmngr_command} ${rc_flags}`
 > 
 > to
 > 
 > 	eval "${dirmngr_command} ${rc_flags}"
 > 
 > (double quotes instead of backticks).  I have not tested this, but 
 > it's possible that it will help.
 > 
 > --apb (Alan Barrett)
 > 

From: Bob Nestor <rnestor@tx.rr.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 11:01:18 -0600

 Changing the eval line in /etc/rc.d/dirmngr doesn't appear to have 
 resolved the issue.

 Just to reemphasize, this isn't a serious problem or something
 that keeps the system from running.  It's just an annoying issue 
 that probably shouldn't happen. I see it on a new install
 because I copy my previously configured rc.conf file to the
 new system and set all the programs to either "NO" or
 comment out the lines while I'm installing things. When
 I'm finished I typically don't have any commented
 program lines or "NO" options left in my configuration.

 On Jan 27, 2014, at 9:50 AM, Alan Barrett wrote:

 > The following reply was made to PR misc/48555; it has been noted by GNATS.
 > 
 > From: Alan Barrett <apb@cequrux.com>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: misc/48555: rc.conf handling of program=yes/no
 > Date: Mon, 27 Jan 2014 17:48:13 +0200
 > 
 > On Mon, 27 Jan 2014, Bob Nestor wrote:
 >> Well, I don't want to come off argumentative here, but I
 >> used the web interface to gnats to file this report.
 >> It doesn't indicate that I have to wrap the lines in
 >> the report.  Maybe this should be filed as a bug
 >> in the gnats web interface.
 > 
 > That sounds like a bug in the web interface.  Sorry I complained 
 > about something that's not your fault.
 > 
 >> As for "program=", ok if that was to difficult to
 >> understand.  Try using "dirmngr=NO" and then
 >> executing "/etc/rc.d/dirmngr restart".  It will
 >> attempt to stop dirmngr first and report an
 >> error. You may need to start dirmngr first
 >> using a "dirmngr=YES" line.
 > 
 > Is this dirmngr from pkgsrc/security/dirmngr?  Try changing 
 > line 56 of /etc/rc.d/dirmngr from
 > 
 > 	eval `${dirmngr_command} ${rc_flags}`
 > 
 > to
 > 
 > 	eval "${dirmngr_command} ${rc_flags}"
 > 
 > (double quotes instead of backticks).  I have not tested this, but 
 > it's possible that it will help.
 > 
 > --apb (Alan Barrett)
 > 

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Mon, 27 Jan 2014 19:48:33 +0200

 On Mon, 27 Jan 2014, Bob Nestor wrote:
 > I see this problem on many other packages as well, including
 > #postfix=YES
 > ipfilter=NO
 > ipnat=No
 > etc.

 Postfix, ipfilter, and ipnat, are all part of the base system. 
 Whatever problem you are seeing is either new or unusual, 
 otherwise it would have been reported before.  Please cut and paste 
 (or write down and type in) the exact error messages, and what you 
 did to trigger the problem.

 > I was afraid the
 > analysis would zero in on a problem in a specific package
 > when it MAY be a more generic problem with the rc scripts
 > themselves.

 Yes, it may, but we really don't have enough information.

 --apb (Alan Barrett)

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Tue, 28 Jan 2014 01:42:17 +0700

     Date:        Mon, 27 Jan 2014 17:05:00 +0000 (UTC)
     From:        Bob Nestor <rnestor@tx.rr.com>
     Message-ID:  <20140127170500.69F35A6488@mollari.NetBSD.org>

   |  Just to reemphasize, this isn't a serious problem or something
   |  that keeps the system from running.  It's just an annoying issue 
   |  that probably shouldn't happen.

 It shouldn't happen, and definitely doesn't happen for me.  I'm not running
 6.1.3 anywhere (yet) but your original PR said ...

    These are minor errors that have been present in earlier releases as well.

 suggesting that you have seen this same thing in earlier releases.

 I have lots of "program=NO" lines in my rc.conf files on various systems,
 and they all work exactly as expected.

 I have no idea where the '[NO' that you're reporting comes from, but
 some of what you're saying (the way you said to test it) suggests a
 misunderstanding of how things are supposed to work.

 First, while (since rc.conf is just a sh script) you can certainly put
 comment lines in it (or comment partial lines), the comments are ignored,
 no different than not being there at all - and for rc.d scripts installed
 from pkgsrc, one of the rules is that you must have a name=YES or name=NO
 line in rc.conf if the script is conditional (has an rcvar, as dirmngr does).

 A line like
 	#dirmngr=YES    (or NO)
 is simply not there at all as far as the rc system is concerned, yet if
 rc.d/dirmng exists, then there must be a dirmngr=YES or dirmngr=NO line in
 rc.conf, or you will get errors reported about the incorrect configuration.

 [Aside: it is known that some people, perhaps many people, don't like this
 rule, as it only applies to pkgsrc added rc.d scripts -- all the scripts
 from the base system have YES or NO settings in /etc/defaults/rc.conf which
 are used if rc.conf doesn't include anything, so #postfix= ... is fine, to
 go back to the default setting for postfix, but #dirmngr=... is not.]

 Second, if you have
 	dirmngr=NO
 you are not supposed to be able to do
 	/etc/rc.d/dirmngr restart

 with it set to no, the dirmngr script is not supposed to be used at all
 (for most purposes) - dirmngr is supposed to be disabled in that state
 (so it makes no sense to attempt to start, stop, or restart it.)  If you
 had it running (dirmngr=YES) and want to disable it, issue the
 	/etc/rc.d/dirmngr stop
 command first, and then change rc.conf from YES to NO so it doesn't restart
 at the next boot.   Don't attempt to do those in the other order.

 If for some reason you need to run rc.d/dirmngr when you have dirmngr=NO
 then you need to use "onestart" or "onestop"  (or perhaps "onerestart" though
 I ave never needed that one, something that is running, and is to be restarted,
 probably should have its config set to YES, not NO).

 (You can use "force" instead of "one" which will then attempt to start/stop
 the service even when various other tests fail - like required files not
 existing, etc.)

 Please check that your /etc/rc.subr hasn't been corrupted, and is the correct
 version for 6.1.3

   |  I see it on a new install
   |  because I copy my previously configured rc.conf file to the
   |  new system and set all the programs to either "NO" or
   |  comment out the lines while I'm installing things.

 I do that kind of thing too, and have never seen anything like you
 report, so unless it is a new bug in 6.1.3, something weird is
 happening on your system.

   |  When I'm finished I typically don't have any commented
   |  program lines or "NO" options left in my configuration.

 I do, I have comments, because I put comments in my rc.conf (they don't
 usually look like #name=NO but they're comments - what the comment says
 is irrelevant to anyone but us humans most of the time, and always here).

 I also have lots of XXX=NO, because I sometimes get trash installed as
 a dependency, that I don't want to run, and because I often way to change
 some of the base system programs that default to on (or kind of on, like
 postfix) to off.   I also have XXX=NO lines for stuff I want enabled, but
 have not finished configuring yet - installed but not yet ready to run.
 (Stuff often lives in that state for months, or even years...) or for
 stuff that would be disabled by /etc/defaults/rc.conf anyway, but which I
 am planning on enabling some day, and I want to be able to quickly work
 out which variable(s) I need to turn on - having them already in rc.conf
 makes it easier than needing to go hunting in /etc/defaults/rc.conf (or
 worse, in the rc.d script itself.)

 I have no problems with stray unwanted error messages at system shutdown time.

 If I were ever to try "/etc/rc.d/posfix stop" (or restart) I would get an
 error, as I have "postfix=NO" (absolutely everywhere), but on shutdown
 postfix is just ignored, and (as it is disabled) there's no attempt to
 stop it, and no stray errors about it.

 kre

From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Tue, 28 Jan 2014 02:20:09 +0400

 On Mon, Jan 27, 2014 at 15:50:01 +0000, Alan Barrett wrote:

 >  Is this dirmngr from pkgsrc/security/dirmngr?  Try changing 
 >  line 56 of /etc/rc.d/dirmngr from
 >  
 >  	eval `${dirmngr_command} ${rc_flags}`
 >  
 >  to
 >  
 >  	eval "${dirmngr_command} ${rc_flags}"
 >  
 >  (double quotes instead of backticks).  I have not tested this, but 
 >  it's possible that it will help.

 Backticks are definitely wrong here.  Eval is unnecessary.  And
 required_* stuff is handled by run_rc_command already.  check_process
 should be used too instead of doing it manually.

 So I'd say, recategorize this against pkgsrc to fix the rc.d file.

 -uwe

Responsible-Changed-From-To: misc-bug-people->pkg-manager
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Sun, 13 Jul 2014 01:14:56 +0000
Responsible-Changed-Why:
As best as we can tell, the problem is that security/dirmngr's rc script is
broken. I've updated the Synopsis: accordingly.


From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: rnestor@tx.rr.com
Subject: Re: misc/48555: rc.conf handling of program=yes/no
Date: Thu, 16 Oct 2014 04:48:11 +0000

 On Mon, Jan 27, 2014 at 10:25:00PM +0000, Valery Ushakov wrote:
  >  >  Is this dirmngr from pkgsrc/security/dirmngr?  Try changing 
  >  >  line 56 of /etc/rc.d/dirmngr from
  >  >  
  >  >  	eval `${dirmngr_command} ${rc_flags}`
  >  >  
  >  >  to
  >  >  
  >  >  	eval "${dirmngr_command} ${rc_flags}"
  >  >  
  >  >  (double quotes instead of backticks).  I have not tested this, but 
  >  >  it's possible that it will help.
  >  
  >  Backticks are definitely wrong here.  Eval is unnecessary.  And
  >  required_* stuff is handled by run_rc_command already.  check_process
  >  should be used too instead of doing it manually.
  >  
  >  So I'd say, recategorize this against pkgsrc to fix the rc.d file.

 On digging some, it seems that the backticks are there because
 dirmngr, instead of doing something sane like writing out a pid file,
 prints "export DIRMNGR_INFO=blahblahblah" when it daemonizes, so
 you're supposed to eval this in the parent shell.

 So that's not it - or at least not overtly. Also, this isn't run at
 shutdown time, although part of the output from this is passed to kill
 in dirmngr_stop and who knows what glop might have got into this.

 To the original submitter if you're still there: what ends up in
 /tmp/dirmngr/dirmngr.info after dirmngr starts (using this rc script)?

 On a further matter, it is not clear where the additional wrapper
 program in files/runDirmngr.c came from but a quick inspection shows
 it has a bug or two...

 -- 
 David A. Holland
 dholland@netbsd.org

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/48555 CVS commit: pkgsrc/security/dirmngr/files
Date: Thu, 16 Oct 2014 04:51:08 +0000

 Module Name:	pkgsrc
 Committed By:	dholland
 Date:		Thu Oct 16 04:51:08 UTC 2014

 Modified Files:
 	pkgsrc/security/dirmngr/files: dirmngr.sh

 Log Message:
 Don't hand-process $required_dirs and $required_files. This is provided
 by the infrastructure. Tangentially related to PR 48555.


 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.5 pkgsrc/security/dirmngr/files/dirmngr.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.