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:
(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.