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

[Colin Watson]

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 at debian.org]