Subject: debconf: db_stop isn't enough to let apacheconfig run
Date: Mon, 15 Apr 2002 00:37:25 -0400 (EDT)
Package: debconf
Version: 1.0.32
Severity: normal
Still working on the twiki package. The postinst uses sh, and does a
. /usr/share/debconf/confmodule
at the top, so it get db_get a few things and set up config files
appropriately. Then it does
db_stop
so that I can do some apache-related reconfiguration. Since my package
requires a new apache module to be enabled (mod_actions, part of the
core but often not enabled) it has to do the DSO scan again:
/usr/sbin/apacheconfig --force-modules
However, this prompts the user Y/n about updating the apache config
files. since db_stop doesn't actually get rid of the frontend, file
descriptor 0 is still frontend, and so the read sits there and nothing
happens...
I *think* I can move enough of the work up above the confmodule
startup, since it doesn't look like it strictly depends on the answers
to the debconf questions. It is tricky enough that I'd rather not, if
I can avoid it; and suppose it isn't the case, there should be some
way around this. (The debconf docs seem to indicate that db_stop
should suffice; suggestions for other ways of handling this are
welcome...)
-- System Information
Debian Release: 3.0
Kernel Version: Linux kuroneko.thok.org 2.4.18 #2 Thu Feb 28 18:28:34 EST 2002 i686 unknown
Versions of the packages debconf depends on:
ii fileutils 4.1-10 GNU file management utilities
ii perl-base 5.6.1-7 The Pathologically Eclectic Rubbish Lister.
package debconf
merge 142944 194152
tags 142944 + patch
thanks
Here is a tested patch to fix the long-standing bug in debconf where
it doesn't restore stdin. It also closes the extranious fd 3 when it
is no longer needed.
Note that this is less work than a reasonably correct and mostly
working fix for the bug in a single package that uses both debconf and
ucf.
Your claims that is bug is documended in debconf-devel(7) are false.
There is no workaround there either.
--- confmodule.save 2004-01-05 19:52:20.000000000 -0800
+++ confmodule 2004-01-07 19:53:39.000000000 -0800
@@ -7,6 +7,12 @@
# Check to see if a FrontEnd is running.
if [ ! "$DEBIAN_HAS_FRONTEND" ]; then
+ if [ ! "$DEBCONF_SAVED_STDIN" ] ; then
+ # save stdin
+ exec 4<&0
+ DEBCONF_SAVED_STDIN=1
+ export DEBCONF_SAVED_STDIN
+ fi
# Ok, this is pretty crazy. Since there is no FrontEnd, this
# program execs a FrontEnd. It will then run a new copy of $0 that
# can talk to it.
@@ -67,4 +73,11 @@
# Cannot read a return code, since there is none and we would block.
db_stop () {
echo STOP >&3
+ exec 3>&-
+ if [ "$DEBCONF_SAVED_STDIN" ] ; then
+ exec 0<&4 4<&-
+ else
+ # needed by dpkg-reconfigure
+ exec 0</dev/tty
+ fi
}
Blars Blarson wrote:
> + # save stdin
> + exec 4<&0
This will likely cause every postinst that uses debconf, starts a
daemon, does not call STOP, and only works around closing cd 3 to hang.
--
see shy jo
Subject: Re: Bug#142944: fix for debconf stdin bug
Date: Sat, 10 Jan 2004 07:18:57 -0800
On Thu, Jan 08, 2004 at 12:56:29PM -0500, Joey Hess wrote:
> Blars Blarson wrote:
> > + # save stdin
> > + exec 4<&0
>
> This will likely cause every postinst that uses debconf, starts a
> daemon, does not call STOP, and only works around closing cd 3 to hang.
Of the 78 packages I found that use debconf, don't do db_stop, and use
one of start-stop-daemon, invoke-rc.d, and /etc/init.d/ , I don't see
anything that works around your leaving fd 3 open. Some daemons will
close extranious file descriptors they are passed, but that should
handle fd 4 as well.
Why would having an extra file-descriptor open for reading (probably
from /dev/tty or /dev/null) cause the postinst to hang?
--
Blars Blarson [email protected]http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
On Sun, 11 Jan 2004, Joey Hess wrote:
> Right, I'm fairly sure that at least a few daemons have been modified
> for debian, perhaps changed to close only fd 3, and would trip over this
> sort of change.
Such debian-modified daemons are buggy. They should not be closing just fd 3,
but be doing it correctly.
On Sun, Jan 11, 2004 at 06:08:01PM -0500, Joey Hess wrote:
> Right, I'm fairly sure that at least a few daemons have been modified
> for debian, perhaps changed to close only fd 3, and would trip over this
> sort of change.
There will be a number of daemons that will only close file descriptors
0, 1 and 2 (I know at least one of my packages does this). Using
db_stop before starting the daemon handles the Debconf control fd.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Andreas Metzler wrote:
> If I understand you correctly this kind of problem depends on the
> _daemon's_ sourcecode and not only on the maintainerscript and cannot
> reliably be found just by checing the latter, but by installing the
> package, can it?
Right, I'm fairly sure that at least a few daemons have been modified
for debian, perhaps changed to close only fd 3, and would trip over this
sort of change.
I regard this as an api change for a library, and if I accept it I will
probably do so by changing the library's "soname" -- which in this case
means adding a new version of /usr/share/debconf/confmodule under a new
name.
I have not decided if I will accept this change, since it conflicts with
how debconf is intended to be used on a philosphical level. Do I really
want to make it easier for postinst scripts to bypass debconf in
prompting the user, an action which is now deprecated by policy?
--
see shy jo
On Sun, 11 Jan 2004 18:08:01 -0500, Joey Hess <[email protected]> said:
> I have not decided if I will accept this change, since it conflicts
> with how debconf is intended to be used on a philosphical level. Do
> I really want to make it easier for postinst scripts to bypass
> debconf in prompting the user, an action which is now deprecated by
> policy?
Policy merely states that you must needs use a debconf like
mechanism to talk to the user -- something that follows the policy
spec. That does not imply that debconf has sole rights -- one could
well have an alternate mechanism to talk to the user, which is policy
compliant, and not debconf.
Hence, stealing away stdin is a bug.
manoj
--
The value of a program is proportional to the weight of its output.
Manoj Srivastava <[email protected]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava wrote:
> Policy merely states that you must needs use a debconf like
> mechanism to talk to the user -- something that follows the policy
> spec. That does not imply that debconf has sole rights -- one could
> well have an alternate mechanism to talk to the user, which is policy
> compliant, and not debconf.
>
> Hence, stealing away stdin is a bug.
No, policy specifies that scripts should prompt by communicating with a
program such as debconf which implements the Debian Configuration
management specification. That specification, as I pointed out before,
requires that said communication be done using stdio.
Debconf does not "steal" anything. If you choose to use it, you
communicate with it using stdio.
--
see shy jo
On Tue, 13 Jan 2004 18:14:38 -0500, Joey Hess <[email protected]> said:
> Manoj Srivastava wrote:
>> Policy merely states that you must needs use a debconf like
>> mechanism to talk to the user -- something that follows the policy
>> spec. That does not imply that debconf has sole rights -- one could
>> well have an alternate mechanism to talk to the user, which is
>> policy compliant, and not debconf.
>>
>> Hence, stealing away stdin is a bug.
> No, policy specifies that scripts should prompt by communicating
> with a program such as debconf which implements the Debian
> Configuration management specification. That specification, as I
> pointed out before, requires that said communication be done using
> stdio.
> Debconf does not "steal" anything. If you choose to use it, you
> communicate with it using stdio.
What if I chose to use two such frontends? There is nothing in
policy that states that each script should communicate with one and
only one debconf like program.
In theoryu, I can ask a dozen questions, each using a
different debconf like program -- and be policy compliant.
How does the second, third and so forth program get hold of
STDIN?
manoj
--
"If people are good only because they fear punishment, and hope for
reward, then we are a sorry lot indeed." Albert Einstein
Manoj Srivastava <[email protected]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava wrote:
> What if I chose to use two such frontends? There is nothing in
> policy that states that each script should communicate with one and
> only one debconf like program.
>
> In theoryu, I can ask a dozen questions, each using a
> different debconf like program -- and be policy compliant.
>
> How does the second, third and so forth program get hold of
> STDIN?
This is not something that I have the least little interest in trying to
support, for a wide variety of reasons that I will not go into here.
--
see shy jo
On Wed, 14 Jan 2004 00:38:52 -0500, Joey Hess <[email protected]> said:
> Manoj Srivastava wrote:
>> What if I chose to use two such frontends? There is nothing in
>> policy that states that each script should communicate with one and
>> only one debconf like program.
>>
>> In theoryu, I can ask a dozen questions, each using a different
>> debconf like program -- and be policy compliant.
>>
>> How does the second, third and so forth program get hold of STDIN?
> This is not something that I have the least little interest in
> trying to support, for a wide variety of reasons that I will not go
> into here.
I can understand that -- you have written debconf, and it
probably perfectly satisfies your needs, and behaves in a fashion
that feels absolutely natural and logical to you. but that does not
mean that the current behaviour is one that would be optimal for
other folks -- especially those considering writing another program
that adheres to the debconf spec.
manoj
--
To err is human, but I can REALLY foul things up.
Manoj Srivastava <[email protected]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava wrote:
> I can understand that -- you have written debconf, and it
> probably perfectly satisfies your needs, and behaves in a fashion
> that feels absolutely natural and logical to you.
That has nothing to do with my reasons for feeling this is a bad idea.
In fact I've done a fair bit of work on transitioning us to cdebconf
(which I did not write) and expect to do more. Moreover, as with most
software I write (or paintings I paint..), I can see problems in debconf
that most people are not particularly aware of.
My reasons have more to do with why we want to use a system like debconf
in the first place, and how something like what you're describing could
seriously undermine its advantages. Things like UI consitency, user
control, a simple frontend-agnostic protocol, etc.
As I said I'd prefer to not go into my reasons in depth here, so I'd
appreciate it if you didn't attribute incorrect reasons to me.
--
see shy jo
Information stored
: Bug#142944; Package debconf.
(Sun, 19 Jan 2025 22:51:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Chris Hofstaedtler <[email protected]>:
Extra info received and filed, but not forwarded.
(Sun, 19 Jan 2025 22:51:02 GMT) (full text, mbox, link).
Control: tags -1 - patch
On Wed, Jan 14, 2004 at 02:31:21AM -0500, Joey Hess wrote:
> That has nothing to do with my reasons for feeling this is a bad idea.
[..]
Looks like the patch is not the patch people are looking for.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.