Hi Peter,
It's certainly possible that this might have been the case on b71 - since then I
do know that Laca has cleaned up the postrun scripts being installed, using a
unique instance of the scripts so that even in multiple packages are installed,
so long as they all have the same postrun tasks, only one is queued. [1]
This results in something like the GConf schema tree being generated only once,
after all the packages have been installed (by restarting the postrun service)
or on reboot.
This is where postrun really is useful - to do otherwise would have meant having
to run several commands on each package install, considerably slowing down
installation as more and more packages are installed - for one package it's
probably not too severe, but it builds up over time if there are a lot.
Darren.
[1] - If you happen to look in /var/spool/postrun after upgrading JDS, but
before a reboot you'll see evidence of this.
Pete Bentley wrote:
> On Wed, Feb 06, 2008 at 09:28:39PM +1100, Darren Reed wrote:
>> Casper.Dik at Sun.COM wrote:
>>> So certainly SOMETHING ran 10,000+ processes. I've seen complaints about
>>> this in other places too.
>> Hmmm, too bad process accounting isn't available early on in bootup,
>> that'd at least allow some evidence gathering.
>
> I have observed these processes running and noted at the time that
> they were children of postrun - a couple of my test boxes are Netra X1's
> and it's particularly obvious on those machines as postrun can take about
> 15 minutes to complete.
>
> Postrun logs its activity to /var/log/postrun.log and the biggest
> culprits seem to be the jobs which use gconftool-2 to install
> desktop preference "schemas".
>
> I last watched this happening on b71, b81 may have improved as
> postrun completes in about 2 minutes on an amd64 box, and I'm pretty
> sure earlier builds were taking 5 minutes or more on the same box.
>
> I plan to upgrade at least one X1 to b81 later this week so I'll get
> a better idea then.
>
> Pete.
