Frank Küster <[EMAIL PROTECTED]> 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
