Kenny MacDonald writes ("Bug#1496: dpkg returns to dselect on SIGSTOP"):
> Package: dpkg
> Version: 0.9375-0
>
> This happened under .75 and I don't know if it is still a problem
> under .77. Ian, you'll know if you changed anything about this.
No, I haven't.
> I was using dselect for the first time (for real), and it is very,
> very nice. However, while it was upgrading my bash.deb, it stopped to
> query about the confile '/etc/profile'. Fair enough, it was
> different. I chose the 'Z' (?) option to suspend and investigate for
> myself. dpkg was then stopped, but instead of starting a shell, it
> returned to the dselect menu, after which I couldn't do anything, as
> dpkg was locked.
I had a bug report like this before. Can you reproduce it ? If you
have two .deb files which have different versions of a conffile in it
you can keep getting dpkg to prompt by editing the conffile once and
then never answering `y' as you install them alternately.
I can't reproduce the problem on my system. I've tried it on the
console, in an xterm and on a serial terminal running a getty_ps
(hacked not to set SIGPIPE to SIG_IGN in the login process); I've
tried it with bash and with tcsh. None of these things have been
helpful.
Is there anything at all odd about your configuration ? What kernel
version do you have ? I'm running 1.2.13, but the problem didn't
appear with 1.2.10 either. What is /bin/sh on your system ?
> I had to quit dselect, manually kill dpkg, find and remove the lock
> file, and then start dselect again. The good news is that my system
> survived the whole episode intact! Phew :)
I should hope it survived the episode. If you find that dselect
and/or dpkg don't recover the system properly when they die or are
killed then that is a bug - though you may need to reinstall some .deb
files to get all the packages in sane and consistent states.
Ian.
