-
one-horse-wagon[
hyc: The build instructions as they are set up now include 25 different dependencies. Only 10 of them are necessary according to the chart. What about throwing out the 15 optional ones, build, and see if the error disappears. If successful, then start bringing back the optional dependencies, one at a time to see which one is the problem.
-
hyc
sounds like a workable approach
-
selsta
one-horse-wagon[: just to confirm the binaries downloaded from getmonero are v0.18.1.2?
-
one-horse-wagon[
Yes. I made sure.
-
selsta
which ubuntu version are you using?
-
selsta
or which OS?
-
one-horse-wagon[
Debian Linux
-
selsta
which boost version?
-
one-horse-wagon[
Debian Linux 11.5
-
one-horse-wagon[
<selsta> "one-horse-wagon: just to confirm..." <- The error occurs when trying to build dircetly from Github. Get Monero works fine.
-
selsta
boost version, not linux version
-
selsta
1.74 from what I can tell
-
one-horse-wagon[
Checked Synaptic manager and it's 1.74
-
one-horse-wagon[
s/dircetly/directly/
-
ArticMine[m]
<fr33_yourself[m]> "I personally think the mass..." <- How about none of the above.
-
ArticMine[m]
Baby boomer perspective. Monero scales way better today for mass adoption than BankAmericard did in 1959 when l was 2 years oild
-
ArticMine[m]
In 19 years Monero can have a higher TPS than VISA
-
ArticMine[m]
Correction 10 years
-
ArticMine[m]
BankAmericard later became VISA
-
jozsef[m]
Good scaling, plus, Monero can already, fairly easily, avoid totalitarian crackdown: just use i2p and no one can tell you are using Monero. But people have to be less chicken that they will be "breaking the law" and feel a little less entitled to convenience.
-
jozsef[m]
Also, there is no need for "mass adoption". Have they been able to stop p2p file exchange, for example? Not even close. Did they "outlaw it", sure, but who cares? The real question that matters is: can they mass-enforce their "laws"? Nope. Only on those who are too chicken and they feel they must be fully law-abiding.
-
rbrunner
I started an attempt to debug the problem from Friday, that self-compiled Monero binaries on Debian don't want to work with SSL, there are connection errors between monero-wallet-cli and monerod
-
rbrunner
I know a little more in the meantime
-
rbrunner
With everything default, the 2 decide on using SSL, and that works - initially: there is a successful SSL handshake, and some successful RCP calls from wallet to daemon
-
rbrunner
But then, after a number of calls that is not allways the same, the connection seems to break down somehow
-
rbrunner
I could not yet see exactly how, the HTTP client simply tells a a given monent: HTTP_CLIENT: Failed to SEND
-
rbrunner
After that error, if you try "refresh" again in the wallet, again some calls work, until there is that error again
-
moneromooo
No more precise message than that ?
-
moneromooo
(I assume you bumped log level)
-
rbrunner
Could not coax the Monero logging system to get more precise than that so far
-
rbrunner
Currently using +net.ssl:TRACE,net.http:INFO
-
rbrunner
Maybe go for +net:TRACE?
-
moneromooo
This message looks like a high-ish level message. Find the send function it's calling, add logs to failure paths. Repeat till you reach the boost layer. There, you should see either an exception (log it) or an error code as param (log it).
-
moneromooo
Sure. Can't hurt if it's quick to get.
-
rbrunner
It got a little bit more specific: Problems at write: Broken pipe
-
moneromooo
Could be the peer cuts off the conncetion. Looks at the logs on the peer side.
-
rbrunner
That seems to come from net_helper.h
-
rbrunner
You mean I should concentrate next on the daemon side?
-
moneromooo
I mean you should read the matching logs on the other side from the log that says "Broken pipe".
-
moneromooo
Well, that's what I suggest anyway. Broken pipe hints that the peer might have cut the connection hard.
-
rbrunner
Any quick idea for a log configuration for the daemon that does not flood me with tons of messages but leaves the intersting ones for this case?
-
moneromooo
If it's offline and local, net*:DEBUG's a good start.
-
moneromooo
Then add X:ERROR if category X seems unintereting and spams a lot.
-
rbrunner
Ok, I try that
-
moneromooo
*throttle*:ERROR is a good one IIRC.
-
rbrunner
Hmm, the daemon does not seem to show anything interesting with +net*:DEBUG -
paste.debian.net/1255713
-
rbrunner
That looks pretty crazy, doesn't it? First transfers a lot of bytes without problems, then breaks down, then recovers and transfers again.
-
rbrunner
On the wallet side
-
rbrunner
And all that only with self-compiled binaries, not with the release binaries ...
-
rbrunner
Thanks for the help, moneromooo. I think I put that away for the moment, let's see whether other people comment
-
moneromooo
If it connects, then it's not cipher suite compatibility.
-
moneromooo
If no other errors, you might have to run with strace to see which syscall fails with EPIPE.
-
moneromooo
That *might* be a clue. Or not.
-
moneromooo
Oh, did you build with those same libs though ? You said yesterday or the day before you had updated your OS very recently.
-
rbrunner
I updated some packages yesterday, but that changed nothing: Had the problem before that, have the problem still now.
-
rbrunner
Hmmm, that strace tool looks like a whole new world to learn if I glance at the help text ...
-
moneromooo
It just logs syscalls, their parameters and return values.
-
moneromooo
strace -o strace.log COMMAND-GOES-HERE
-
moneromooo
Gotta use -f or -ff if your command forks.
-
one-horse-wagon[
I followed up on yesterday. I built the monero binaries from Github after throwing out all of the optional dependencies. I made sure the necessary binaries were all there. I had to add libboost-all-dev and libzmq3-dev. monerod is running fine. When I started up monero-wallet-cli, it threw an error--"refresh failed: no connection to daemon. Please make sure daemon is running.. Blocks received: 0"
-
one-horse-wagon[
My conclusion is one of the necessary dependencies is causing the error and not the optional dependencies.
-
moneromooo
Maybe you can go through the lib dependencies and log the versions of each on your system and on the gitian setup.
-
moneromooo
openssl and boost are the main suspects here.
-
rbrunner
one-horse-wagon: Can you read my debugging results from a few hours ago in the backlog?
-
rbrunner
It's even crazier than simply no connection at all :)
-
one-horse-wagon[
I looked at your report when you first posted it. I would like to say I can see where the problem lies but i can't.
-
rbrunner
Alright. I am also hesitating to go even deeper into this rabbit hole. It will probably turn out to be something stupid, or simply vanish with the next Boost or OpenSSL update
-
one-horse-wagon[
Libboost has a new version out --1.8--released in August I believe. Could it possibly help?
-
selsta
rbrunner: you can try to manually compile latest boost and openssl and and set it in cmake
-
rbrunner
Thanks, maybe I will try that. No promises yet.
-
selsta
debian seems to have boost 1.74 which is 2 years old and no one reported issues with it yet
-
rbrunner
Yup: Version: 1.74.0.3
-
selsta
rbrunner: is this something you want to look into?
monero-project/monero #8560
-
selsta
not sure who else to ask regarding Windows
-
rbrunner
Alright, I will experiment a little with that tomorrow evening. Maybe I am lucky and see something. Probably not because Windows :) But still worth a try
-
duggavo[m]
monero-wallet-rpc appears to make all the RPC requests time out while it's syncing up with the daemon. Is this wanted or it is a bug?
-
duggavo[m]
* monero-wallet-rpc appears to be making all the RPC requests time out while it's syncing up with the daemon. Is this wanted or it is a bug?
-
esai[m]
hello guys, I am a Blockchain dev
-
esai[m]
If you want my help, I will.
-
hyc
duggavo[m]: the wallet should always reply "BUSY" until syncing is done
-
hyc
(hm. mebbe I'm thinking of the daemon)
-
duggavo[m]
<hyc> "duggavo: the wallet should..." <- I've had that error in the past with the daemon, not with the wallet
-
duggavo[m]
wallet just doesn't answer to the RPC requests
-
hyc
yeah it's been a while since I've sync'd an rpc wallet. usually it runs 24/7 so it's always in sync already
-
plowsof
i remember moo saying rpc is single threaded , as in, it doesn't respond when syncing ? i just "loop until rpc requests stop timing out" then i know its synced/ready
-
one-horse-wagon[
<selsta> "debian seems to have boost 1...." <- Since the release of boost 1.74, there have been 6 upgrades to the present 1.80. The linux kernel in Debian Linux is version 5.10 and since then there are now 9 upgrades to 5.19. Obviously, bugs have have fixed with the upgrades. I just wonder if I have been "chasing rainbows" with older buggy software. My question is would an up to date linux distro like Arch which can keep up with
-
one-horse-wagon[
the latest in all packages be better to run instead of Debian Linux?
-
one-horse-wagon[
* like Arch, which, * all packages, be
-
selsta
I think it would be best to manually compile newest boost and openssl as a test
-
selsta
to see if this solved the issue
-
selsta
on debian