[MacPorts] #60509: Upgrading ports sometimes breaks internet connection
MacPorts
noreply at macports.org
Mon May 18 01:23:49 UTC 2020
#60509: Upgrading ports sometimes breaks internet connection
---------------------+--------------------
Reporter: iEFdev | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version: 2.6.2
Resolution: | Keywords:
Port: |
---------------------+--------------------
Changes (by ryandesign):
* cc: jmroot (added)
Comment:
Looking back at the kernel panic logs I've saved from our 10.6 i386
builder, all of them are either in `ping` or `grep` or `cut`.
When MacPorts determines a server's ping time, it does so by running `ping
-noq -c3 -t3 $host | grep round-trip | cut -d / -f 5`.
The code is in `proc portfetch::sortsites` in https://github.com/macports
/macports-base/blob/master/src/port1.0/fetch_common.tcl.
MacPorts spawns `ping` and `grep` and `cut` processes for each host whose
pingtime it needs to check. It doesn't need to check those that it checked
within the past 24 hours, but if you haven't used MacPorts in over a day,
then it needs to recheck them all.
An idea about why perl modules specifically might trigger the problem is
that our list of perl cpan mirror sites is very large. There are currently
191 hosts in the list. Add to that the 16 MacPorts mirrors and that's 207
hosts to check all at once, for which MacPorts spawns 621 simultaneous
processes. Each process surely needs at least one file descriptor. It
could be that this is exceeding the number of available file descriptors,
especially if your computer has many other open files already and/or has
been online for awhile and you've been running programs that have leaked
file descriptors (opened them but forgot to close them). It's possible
that MacPorts itself is still leaking file descriptors somewhere.
[ticket:50986 One such bug] was already fixed previously. And if you are
running out of file descriptors, then it is not at all surprising that
Internet access, the ability to open programs and read and write files,
and pretty much everything else about the computer would cease to
function.
Possible solutions:
1. We could trim the list of perl cpan [https://github.com/macports
/macports-ports/blob/master/_resources/port1.0/fetch/mirror_sites.tcl
mirrors] to a more reasonable number.
2. MacPorts base could spawn only a `ping` process for each host and
perform the equivalent of the `grep` and `cut` commands using Tcl string
processing.
3. MacPorts base could limit the number of hosts that it checks
simultaneously.
--
Ticket URL: <https://trac.macports.org/ticket/60509#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list