Closed aalmenar closed 1 year ago
The cache is corrupted, the solution is in the message:
ERROR: Delete the cache file .cache/ripe/ripe.db.gz
I'm getting the same error consistently on macOS. It only happens with the ripe data.
From a clean slate (no cache), it does not throw an error, but it doesn't produce a CSV. Then if I try again, it throws the Zlib error. There is nothing in the error log.
Do you know how the cache could be getting corrupted?
From a clean slate (no cache), it does not throw an error, but it doesn't produce a CSV.
This is weird, the process should exit with some success or error state. It may take long, but it should always exit with some message.
The only case that I can think of for the process to exit without any message is if the OS kills it for using too much memory. But it is strange for this software.
Are you sure the process exists and not just stuck? the connection is stable? the process has write permissions? enough memory on the machine?
Then if I try again, it throws the Zlib error. Do you know how the cache could be getting corrupted?
Probably the process didn't finish to download the whois dump. The ripe dump is quite large as a file.
I thought it was strange too! Here's an example: (everything except ripe is in cache)
➜ ./geofeed-finder-macos-x64 -o "result.csv"
[ripe] Downloading whois data
[afrinic] Using cached whois data
[apnic] Using cached whois data
[afrinic] Parsing whois data: inetnum,inet6num
[apnic] Parsing whois data
[arin] Using cached whois data: inetnum
[lacnic-rir] Using cached whois data
[lacnic-rir] Parsing whois data: inetnum
[arin] Using cached whois data: inet6num
[lacnic-rir] Using cached whois data
[lacnic-rir] Parsing whois data: inet6num
➜ echo $?
0
The process exits cleanly without an error message after about 20 seconds. It uses about ~160 MB of memory so shouldn't be killed by the OS.
The broken ripe file ends up being between 500 KB and 10 MB - so I agree I think it's just failing to download. I don't have any other issues with my connection, though.
I tried adding a long download timeout with -d 1800
but the same thing happens and the process exits well before the timeout.
are you able to download it in the command line with wget ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz
?
Are you using the binary or the source code?
Just for giggles / as an additional data-point: I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook. (the sha1sum for the binary is: 69ac83d16d9e1ababb6a9a45835b4abdb50d481a)
This ran fine for me (other than logging a bunch of
Cannot retrieve 199.182.160.0 ECONNRESET
Cannot retrieve 199.182.132.0 ECONNRESET
Cannot retrieve 199.182.136.0 ECONNRESET
...
:-) ) and mine peaked at ~500MB of RAM.
The .cache/ripe/ripe.db.gz
file I end up with is 348MB.
Are you using the binary or the source code?
The last few tests have been using the binary but I've tried both.
are you able to download it in the command line with wget ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz?
Yep, that downloaded fine! Thanks - that's nice as a workaround for now.
I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook.
That's my setup too, so I assume it's something on my end - just odd that the process seems to die with no error message.
I just fetched the latest release (1.6.6) binary for OSX, and ran it under macOS Ventura on an M1 Macbook.
That's my setup too, so I assume it's something on my end - just odd that the process seems to die with no error message.
I never tested this on an M1 actually. I don't have access to one, but if you are available we could do a couple of experiments. To start with, could you confirm that you get the same error if you run directly the source? What node version?
Sorry for the trouble - I can't reproduce it anymore. From a clean slate, both methods (binary and source) seem to work fine now. I can only guess that there was something killing the connection but honestly have no idea! :(
ok, then I'm going to close this.
When executing the macos binary always produces this output: