Bug#396835: tetex-bin postinst take unlimited amount of time and ram (kpsewhich took 600M and 14h)
Frank Küster <frank@debian.org> wrote:
> But that
>
> - does not explain why tetex-bin's postinst was called at all before
> tetex-base' was ready
My hypothesis is that dpkg somehow "forgot" that tetex-bin.postinst was
running (maybe because dpkg was killed). Then, if you install or upgrade
tetex-base, your can have such a "ps axf" output. I don't think apt is
so brain-damaged as to install tetex-base and tetex-bin simultaneously
and configuring tetex-bin before tetex-base.
> - why dpkg was killed.
That, I don't know. Maybe the user killed it, maybe it was run in an ssh
session and the network connection broke... It *might* also be that dpkg
was killed due to a segmentation fault, though it seems to be very rare
(but that can happen if the hardware is buggy). I don't know.
> The process ID of tetex-bin's postinst (30027) is way higher than that
> of tetex-base's, 12063, which in turn is just by one higher than dpkg's.
I have trouble reasoning on PIDs here, because of this:
> 30211 pts/11 S 0:00 \_ /bin/sh /usr/bin/fmtutil --all
> 6929 pts/11 S 0:00 \_ /bin/sh /usr/bin/fmtutil --all
> 6930 pts/11 S 0:00 \_ /bin/sh /usr/bin/fmtutil --all
> 6931 pts/11 R 11:09 \_ kpsewhich --var-value=TEXMFMAIN
As you can see, the PIDs don't seem to vary monotonically...
> Maybe in fact the problem is that tetex-bin's postinst never finished
> from a previous try, but is "harmless", and then when tetex-base is
> configured "again" the memory and CPU gets eaten up?
That's what I was thinking. But I admit we've got a bunch of "maybe"s
here...
--
Florent
Reply to: