Solved Portsnap fetch update issue?

M

Mayhem30

Is anyone else having issues with portsnap fetch update "hanging" for an extensive period of time? It's been an issue for the last week or so.

It only gets this far before doing nothing for quite sometime :
Code: 
$ sudo portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from isc.portsnap.freebsd.org...
Then eventually it shows this :
Code: 
Fetching snapshot tag from isc.portsnap.freebsd.org... failed.
Fetching snapshot tag from sourcefire.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Tue Dec 22 04:07:32 PST 2015 to Tue Dec 22 12:01:54 PST 2015.
I'm assuming FreeBSD is having server issues?
 
Your network could be misconfigured, it could be your firewall blocking it. Can you update your base-system, or try root without sudo?
 
The base system is up to date (I check that quite frequently) and I haven't changed any configs on the server for sometime - including firewall configuration.

My dedicated server just can no longer communicate with isc.portsnap.freebsd.org
Code: 
# ping isc.portsnap.freebsd.org
PING portsnap.isc.freebsd.org (149.20.53.25): 56 data bytes
36 bytes from 149.20.65.46: Destination Host Unreachable

# traceroute isc.portsnap.freebsd.org
traceroute to portsnap.isc.freebsd.org (149.20.53.25), 64 hops max, 40 byte packets
 1  router.dfw-datacenter.com (72.9.154.1)  0.293 ms  0.414 ms  0.263 ms
 2  72.249.128.161 (72.249.128.161)  0.767 ms  0.886 ms  0.648 ms
 3  206.123.64.217 (206.123.64.217)  0.269 ms  0.274 ms  0.268 ms
 4  xe-4-2-0.er2.dfw2.us.above.net (64.124.196.225)  0.432 ms  0.422 ms  0.415 ms
 5  ae7.cr2.dfw2.us.zip.zayo.com (64.125.20.233)  19.515 ms
  ae-2.r23.dllstx09.us.bb.gin.ntt.net (129.250.6.128)  0.994 ms  0.998 ms
 6  ae-8.r23.snjsca04.us.bb.gin.ntt.net (129.250.4.154)  40.426 ms  78.989 ms  39.469 ms
 7  ae-45.r01.snjsca04.us.bb.gin.ntt.net (129.250.3.175)  39.949 ms
  ae3.cs2.lax112.us.eth.zayo.com (64.125.29.21)  37.165 ms  37.017 ms
 8  ae-4.r06.plalca01.us.bb.gin.ntt.net (129.250.4.118)  38.167 ms  38.187 ms
  ae-4.r05.plalca01.us.bb.gin.ntt.net (129.250.5.32)  38.320 ms
 9  ae-1.isc.plalca01.us.bb.gin.ntt.net (129.250.197.22)  41.566 ms
  ae-0.isc.plalca01.us.bb.gin.ntt.net (128.241.1.78)  41.566 ms  41.355 ms
10  int-0-0-1-0.r1.sql1.isc.org (149.20.65.10)  40.661 ms  40.820 ms
  149.20.65.46 (149.20.65.46)  41.471 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * *^C
It's only having issues with that mirror, as it's finding the next one on the list just fine :
Code: 
Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found.
Fetching snapshot tag from isc.portsnap.freebsd.org... failed.
Fetching snapshot tag from sourcefire.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
 
You can try taking a look in /etc/portsnap.conf at the line SERVERNAME=, mine uses portsnap.FreeBSD.org as the address.

There's another option of using net/svnup to update the ports-tree, that takes editing /usr/local/etc/svnup.conf, and using the argument you set to download the ports-tree. svn updates more frequently than portsnap which uses more quality assurance.
 
I've had a similar issue if I don't put in a server name lately. If you look in /var/db/portsnap/ you'll see a file called serverlist. I've been using (as I'm in the Northeast US)
ec2-ap-northeast-1.portsnap.freebsd.org (always planning to put it in /etc/portsnap.conf and forgetting.)

However, I run it at command line with portsnap -s ec2-ap-northeast-1.portsnap.freebsd.org and then there's no hangin.
 
Problems with the portsnap(8) servers seem to be increasingly prevalent during the last year or so. I'm curious if portsnap(8) is headed for deprecation in the near to medium term.

svnlite(1) works just as well if not better and seems to be more reliable in my experience. I haven't had a single problem in the last two years I've been using it or devel/subversion to sync the ports tree on my systems.
 
protocelt said:
Problems with the portsnap(8) servers seem to be increasingly prevalent during the last year or so. I'm curious if portsnap(8) is headed for deprecation in the near to medium term.

svnlite(1) works just as well if not better and seems to be more reliable in my experience. I haven't had a single problem in the last two years I've been using it or devel/subversion to sync the ports tree on my systems.
Click to expand...

I like switch from portsnap to devel/subversion. Do I need first remove ports or is okay just run svn please?
 
drhowarddrfine said:
So is everything under /usr/ports/ removed including distfiles, Makefile, etc.? Or just each port category themselves?
Click to expand...
You'll want to delete all files and folders in /usr/ports. If you want, you can copy the /usr/ports/distfiles directory somewhere else temporarily as not to have to download all the distfiles again once /usr/ports is repopulated, but it won't cause any harm otherwise to delete that directory as well.
 
The distfiles really shouldn't be under /usr/ports/distfiles but that's still the default location unfortunately. I would move them to a more hier(7) compatible location such as /var/cache/distfiles and set this in /etc/make.conf:

Code: 
DISTDIR=/var/cache/distfiles
 
kpa said:
The distfiles really shouldn't be under /usr/ports/distfiles but that's still the default location unfortunately. I would move them to a more hier(7) compatible location such as /var/cache/distfiles and set this in /etc/make.conf:

Code: 
DISTDIR=/var/cache/distfiles
Click to expand...

I've wondered about this myself. /var does seem like a more suitable location. I assume the default is an artifact of history.
 
I've told committers that putting distfiles and packages in the portstree is asinine but my views didn't gain traction.
Even worse is dumping the work directory right in the port!

On DPorts, the default locations are /usr/distfiles, /usr/packages, and /usr/obj/dports/<category>/<portname>/ (for each port)
 
I think paths that are used by build(7) would make more sense for the port work directory, that would be /usr/obj/usr/ports/<category>/<port>/work by default and the /usr/ports part would of course vary depending on where the ports tree is located.
 
We used to have /usr/obj/usr/dports/<category>/<port>/work but we got rid of "/work" because it was the only item in "/<port>" and it didn't make sense. So we killed it and saved some typing.
 
To be clear, we redefined it so the tree location is not considered, it's an absolute path.*
Moreover it automatically deletes empty directories when "clean" command is issued and leaves an empty tree.
I don't expect freebsdFreeBSD to follow suit, but it is really nice.

*edit: of course you can redefine that in /etc/make.conf with the typical variables.
 
marino@ said:
I don't expect FreeBSD to follow suit, but it is really nice.
Click to expand...
Why? It makes sense and sounds like a good idea to me and I can't immediately think of a reason for push-back other than "I/we don't like change...". I'm not a developer so there of course may be a reason I don't know about.
 
Too much legacy and all it takes is one or two greybeards to say they don't like to change (especially towards DragonFly) and that kills it. But mostly it's the same old reasons: inertia and lack of 100% consensus
 
You must log in or register to reply here.
Back
Top