Debian Bug report logs - #469354
debconf: dpkg-reconfigure should acquire dpkg lock

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@ubuntu.com>

To: submit@bugs.debian.org

Subject: debconf: dpkg-reconfigure should acquire dpkg lock

Date: Tue, 4 Mar 2008 19:57:55 +0000

[Message part 1 (text/plain, inline)]

Package: debconf
Version: 1.5.19
Severity: normal
Tags: patch
User: ubuntu-devel@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch hardy

Ian Jackson pointed out that dpkg-reconfigure doesn't acquire the dpkg
lock while running maintainer scripts, and should; otherwise it could
race with a simultaneous 'dpkg -i' provided that the other package
doesn't use debconf, and bad things could conceivably happen. This will
become of more practical importance once dpkg supports triggers, because
then dpkg-reconfigure ought to arrange to process any triggers activated
by the maintainer scripts, and some confusion would arise if dpkg were
running at the same time.

How does this patch look? I thought it was big enough that I ought to
post it for review rather than just committing.

Thanks,

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

[debconf.dpkg-lock.diff (text/x-diff, attachment)]

Message #10 received at 469354@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Colin Watson <cjwatson@ubuntu.com>, 469354@bugs.debian.org

Subject: Re: Bug#469354: debconf: dpkg-reconfigure should acquire dpkg lock

Date: Tue, 4 Mar 2008 15:47:53 -0500

[Message part 1 (text/plain, inline)]

Colin Watson wrote:
> Ian Jackson pointed out that dpkg-reconfigure doesn't acquire the dpkg
> lock while running maintainer scripts, and should; otherwise it could
> race with a simultaneous 'dpkg -i' provided that the other package
> doesn't use debconf, and bad things could conceivably happen. This will
> become of more practical importance once dpkg supports triggers, because
> then dpkg-reconfigure ought to arrange to process any triggers activated
> by the maintainer scripts, and some confusion would arise if dpkg were
> running at the same time.

Hmm, this seems a bit theoretical. The main likelihood of conflict would be
if it were the same package being installed and dpkg-reconfigured at the
same time, but then the package would use debconf and debconf's existing
locks would prevent it in most cases (a few dbdrivers don't need any
locking).

The sort of races or other conflicts that occur when installing and
configuring two separate packages can probably just as likely occur when
installing a package and doing other random sysadmin work concurrently.
(This is a bit theoretical too. :-) For example, dpkg-divert can lose
information in /var/lib/dpkg/diversions if two instances are run
concurrently and race just right; neither it nor update-alternatives do
any locking. I frequently run these as an admin -- I also sometimes run
postinst scripts directly as an admin.

> +sub linux_struct_flock {
> +	my $type = shift;
> +	my $whence = shift;
> +
> +	# On Linux, l_start and l_len might be either 4 bytes or 8 bytes
> +	# depending on how perl was compiled. Since everything from l_start
> +	# onwards will be zero, we just say 8 bytes for both and hope. (In
> +	# other words, strictly speaking the pack format should be 's2l2i'.)
> +	return pack('s2l4i', $type, $whence, 0, 0, 0, 0, 0);
> +}

Trying do flock locking from perl reliably and portably is in my
experience a nightmare^Wlosing proposition, and I have no desire to try
to maintain code that does it. I've gone as far as to completly redesign
programs that needed a flock lock from perl in the past.

Note that this bug would be much easier to fix in cdebconf's
dpkg-reconfigure ..

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 469354@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Joey Hess <joeyh@debian.org>, 469354@bugs.debian.org

Subject: Re: [Debconf-devel] Bug#469354: debconf: dpkg-reconfigure should acquire dpkg lock

Date: Mon, 29 Sep 2008 19:20:50 +0100

On Tue, Mar 04, 2008 at 03:47:53PM -0500, Joey Hess wrote:
> Colin Watson wrote:
> > Ian Jackson pointed out that dpkg-reconfigure doesn't acquire the dpkg
> > lock while running maintainer scripts, and should; otherwise it could
> > race with a simultaneous 'dpkg -i' provided that the other package
> > doesn't use debconf, and bad things could conceivably happen. This will
> > become of more practical importance once dpkg supports triggers, because
> > then dpkg-reconfigure ought to arrange to process any triggers activated
> > by the maintainer scripts, and some confusion would arise if dpkg were
> > running at the same time.
> 
> Hmm, this seems a bit theoretical. The main likelihood of conflict would be
> if it were the same package being installed and dpkg-reconfigured at the
> same time, but then the package would use debconf and debconf's existing
> locks would prevent it in most cases (a few dbdrivers don't need any
> locking).

One reason it's not entirely theoretical is that, if you were running
dpkg-reconfigure in another window and forgot about it and then tried to
do an upgrade, this means that the failure will only occur when some
maintainer script tries to start up debconf rather than much earlier,
and thus will leave packages in an unconfigured state rather than just
refusing to upgrade. I think it would be better to refuse up-front.

(This recently came up in practice; we got a bug report because a
package failed to configure, which turned out to be due to the debconf
lock being held. I don't think we'd have got the report if dpkg had just
failed up-front.)

Have you thought about the trigger activation issue at all? I think that
one is a potential gotcha for packages that both use debconf and call
dpkg-trigger conditionally in their maintainer scripts. I'm not sure if
we have any such packages right now but I'm sure it's only a matter of
time.

> > +sub linux_struct_flock {
> > +	my $type = shift;
> > +	my $whence = shift;
> > +
> > +	# On Linux, l_start and l_len might be either 4 bytes or 8 bytes
> > +	# depending on how perl was compiled. Since everything from l_start
> > +	# onwards will be zero, we just say 8 bytes for both and hope. (In
> > +	# other words, strictly speaking the pack format should be 's2l2i'.)
> > +	return pack('s2l4i', $type, $whence, 0, 0, 0, 0, 0);
> > +}
> 
> Trying do flock locking from perl reliably and portably is in my
> experience a nightmare^Wlosing proposition, and I have no desire to try
> to maintain code that does it. I've gone as far as to completly redesign
> programs that needed a flock lock from perl in the past.

Acknowledged, but I don't see any other way to do it in debconf. Maybe
dpkg should ship a Dpkg::Lock module which lets you acquire it from
Perl, and then you wouldn't have to maintain it in debconf ...

-- 
Colin Watson                                       [cjwatson@debian.org]

Send a report that this bug log contains spam.