Ticket #1068 (closed defect: worksforme)

Opened 9 years ago

Last modified 9 years ago

* fork() failed (paludis::ProcessError)

Reported by: ulmo Owned by:
Priority: Sometime Milestone:
Component: clients/paludis Version: 0.56.0
Keywords: Cc:
Blocked By: Blocking:
Distribution: Gentoo

Description

Getting lots of these fork errors in paludis 0.56.0. Here's an example:

ESC[33m>>>ESC[0m Completed ebuild phases loadenv tidyupM ESC[1;32m*ESC[0;0m Messages log: /var/log/paludis/1292470692-install-sys-apps_iproute2-2 .6.35-r2:0::gentoo.messages

ESC[32;01m*ESC[0m Regenerating environment...

Regenerating /etc/ld.so.cache...

ESC[32;01m*ESC[0m Done regenerating environment ESC[32;01m*ESC[0m Updating CONFIG_PROTECT and CONFIG_PROTECT_MASK caches.

Unhandled exception:

  • In program /usr/bin/paludis --dl-fall-back as-needed --dl-reinstall if-use-changed --d

l-reinstall-scm always --dl-upgrade always --show-reasons summary --continue-on-failure if -independent -i installed-packages:

  • When performing install action from command line:
  • When executing install task:
  • When triggering hook 'install_pre':
  • When running hook script '/usr/libexec/paludis/hooks/install_pre/log.bash' for hook 'i

nstall_pre':

What I have to do to restart is basically reissue the install command, but skip the packages already completed somehow; either I redesignate what has to be done in the install command for reinstalls, or for the commands that only do upgrades and such, that will automatically not have to do the stuff it's already done with (which is just a rerun of the same command and it has less to do left over). However, what does NOT work is re-running the exact same installs (e.g., for a reinstall, which always does everything on the command line), because it will always fail (at the same spot? I forget, but I have a humungous scriptfile with all the rebuilds if you need details).

Since I upgraded gcc's (now at 4.4.4), I decided to rebuild everything.

If someone could give me some suggestions for what to look for, it would be nice.

BTW, if I didn't break my upgrades down into segments (system, python & perl rebuilds, major big programs that pull a lot in like mplayer and kde-meta, etc., and finally installed-packages), then it'd be about 1500 packages. As it is, it usually does builds in sizes of between 100 and 500 packages for each little stage I do.

paludis has been crashing usually at around 100 or so packages.

I believe this bug isn't in the version I had prior to 0.56.0: for instance, when I did my final "system" rebuild, it did 540 packages nonstop without fail. I decided to upgrade paludis to try to squash some little bugs along the journey of a complete system upgrade, and that's when this bug reared its head.

The workaround I described seems to work well enough, although I don't know for sure. A lot of packages built anew (from the ground up as it were since I did a complete system rebuild piecemeal) seem to be fine, though, like mplayer. However, a lot of what was built was with a prior good version of paludis.

Change History

comment:1 Changed 9 years ago by ciaranm

fork() failing is likely to be down to you running out of memory, or having process limits in place.

Can you strace -f and get the return code and errno for the failing fork()?

comment:2 Changed 9 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to worksforme

Can't reproduce this.

Note: See TracTickets for help on using tickets.