< setpill>
what is the recommended way to cleanly shut down bitcoind running in the background?
< setpill>
seems like sending sigterm does an unclean shutdown
< belcher>
setpill this is a question more for #bitcoin than here, but try running `bitcoin-cli stop`
< setpill>
belcher: it's related to the default systemd service file of bitcoin core not shutting it down cleanly when using `systemctl stop bitcoind.service`
< setpill>
hm it might also be a timeout issue
< setpill>
ie. systemd going for the sigkill before the db has been flushed to disk
< jonasschnelli>
Unfortunate that our current ChaCha20Poly1305@Bitcoin implementation works on a single buffer.
< jonasschnelli>
Makes it harder to avoid vector::insert's / possible relocations
< jonasschnelli>
Ideally the AEAD would work on three buffers, 1| the "header" (3 byte packet length a.k.a. AD + command), 2| the message payload, 3| the 16byte MAC tag
< provoostenator>
setpill: that would be useful to know; I imagine that can cause serious problems for low end devices, e.g. some raspebbery pi that needs to reboot after a system update
< provoostenator>
I use more or less the default systemd example one of my own machines and haven't had issues with unclean shutdowns that I know, but I never stress tested that.
< setpill>
provoostenator: it depends on how big your dbcache is and how much syncing you have done since the last time bitcoind was started
< setpill>
I just tried `bitcoin-cli stop` (rather than `systemctl stop bitcoind.service`) and it took almost 9 minutes.
< setpill>
But that's with a node that had synced non-stop from ~block 500000
< setpill>
And with a 15GB dbcache
< setpill>
I think setting `TimeoutStopSec=infinity` in the bitcoind.service file should fix it properly (though you'll want to be cognizant that shutdown of your device might take ages)
< setpill>
Will make a PR
< provoostenator>
That seems reasonable at first glance, but I'm no systemd expert. I assume reboot will run out of patience?
< setpill>
Not sure about that, good question.
< provoostenator>
Is it possible to "fail" the stop, instead waiting forever?
< setpill>
Well that's what it does now, I guess.
< provoostenator>
At least it makes sense to ask for the user to intervene if the node doesn't gracefully stop.
< setpill>
Simply sigkills.
< setpill>
It's possible to disable the sigkill at end of timeout.
< setpill>
But imho that's worse because it doesn't properly restart the service.
< provoostenator>
No that's not what I mean. I mean "systemctl stop bitcoind" could return an error without doing sigkill, basically "I can't stop this process"
< setpill>
Ie. `systemctl restart bitcoind.service` is a `stop` followed by a `start`
< setpill>
If the `stop` timeouts without successfully stopping the service, it will not perform the `start`
< setpill>
Which might be worse than the restart happening 10 minutes later than you'd expect, but still as soon as possible.
< provoostenator>
From the docs: "If a service of Type=notify sends "EXTEND_TIMEOUT_USEC=…", this may cause the stop time to be extended"
< setpill>
provoostenator: that might *also* be an option yes. I will open an issue about this so these points can be recorded for later reference
< provoostenator>
If we wanted to switching from type "forking" to type "notify" that involves changes in the code to use sd_notify. Systemd docs seem to prefer that.
< setpill>
Just feels conceptually "wrong" to let the shutdown timeout when it's still hard at work and has not frozen at all.
< bitcoin-git>
[bitcoin] davereikher opened pull request #16570: Make descriptor tests deterministic (master...make_descriptor_tests_deterministic) https://github.com/bitcoin/bitcoin/pull/16570
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16571: gui: Make Bitcoin Core logo pure black (master...1908-guiIcoPureBlack) https://github.com/bitcoin/bitcoin/pull/16571
< MarcoFalke>
#proposedmeetingtopic Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak?
< luke-jr>
I tried to make a flatpak but couldn't get it to work :/
< elichai2>
I added the control block to the `SignatureData` struct, and I'm filling it in `ProduceSignature`(right now it's greedy and takes the first script that it can sign for) but for the signing support itself i'll wait for achow101's native descriptors PR :) until then i'll rebase my psbt stuff to use the new descriptor
< dongcarl>
Wondering anyone had thoughts on a generic feature-signaling message for non-monotonic features that don't fit in the protocol version model
< dongcarl>
Has there been prior art?
< sipa>
BIP 36 perhaps
< sipa>
long ago
< dongcarl>
Was there any reason why this wasn't adopted? Or just no one implemented?
< dongcarl>
#proposedmeetingtopic [maybe short] generic feature-signaling message for non-monotonic features that don't fit in the protocol version model (like BIP 36)
< sipa>
FWIW, i think the "sendX" type negotiation works pretty well
< dongcarl>
sipa: works pretty well = overhead + the extra message types not that big of a deal?
< sipa>
they're sent exactly once
< dongcarl>
true... okay perhaps this isn't that big of a problem.
< * dongcarl>
wishes there were a #cancelproposedmeetingtopic
< MarcoFalke>
I'd rather stick with some GitHub specific stuff that works than to ditch GitHub specific stuff and make running the tests harder for developers
< wumpus>
there's one by MarcoFalke: Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak
< dongcarl>
wumpus: could you remove my proposed?
< wumpus>
dongcarl: moneyball already did
< MarcoFalke>
We can always keep the bitcoin-builds as a backup fallback ci
< phantomcircuit>
MarcoFalke, it really depends on how powerful their build servers are, for a relatively small price a very powerful server could be acquired and used for builds
< MarcoFalke>
#proposedmeetingtopic GitHub ci
< wumpus>
#topic High priority for review
< MarcoFalke>
phantomcircuit: Not every developer has a credit card, even if they can afford the price of the ci
< phantomcircuit>
MarcoFalke, no what im saying is that we could collectively buy a server that could do the builds, in general things where you're buying "packaged" cpu time from third parties end up being very expensive
< jnewbery>
wumpus: there was at least a bug in the test case which I'm fixing now
< jnewbery>
I would appreciate rereview after I push that fix
< wumpus>
jnewbery: sure
< MarcoFalke>
jnewbery: Will take another look in the next couple of days
< MarcoFalke>
Also, I plan to review sdaftuar's pr (it has been on my list for a while, but I haven't gotten to it yet)
< wumpus>
thanks
< fanquake>
wumpus: first topic?
< wumpus>
we're done with high priority for review?
< * jonasschnelli>
waves at #16202 (quick review, on the path to p2p encryption)
< wumpus>
#topic Who wants to volunteer as co-maintainer of the Bitcoin Core flatpak (MarcoFalke)
< achow101>
who currently maintains it?
< jonasschnelli>
can someone explain flatpak?
< MarcoFalke>
It isn't created yet
< MarcoFalke>
jonasschnelli: It is like a snap package
< wumpus>
it's a distribution agnostic binary package distribution format
< MarcoFalke>
Different name, though
< wumpus>
for linux
< jonasschnelli>
Okay. Sounds acceptable.
< wumpus>
it's especially good for GUI applications, it has some features like sandboxing and desktop UI integration which simply dropping static binaries has not
< MarcoFalke>
I will be a repository hosted under the flatpak org, so not in our org. Which is why I am asking for co-maintainers.
< achow101>
they just announced it today, it's in beta
< wumpus>
I've never heard of github ci
< MarcoFalke>
moneyball: Yes, according to achow101
< moneyball>
when Pieter, Cory, Matt, and I visited GitHub, they demo'd this
< wumpus>
but if it can take over what travis does and does it beter, without too much work from our side, that'd be very useful
< moneyball>
cfields has strong views on this
< MarcoFalke>
wumpus: Jup, agree
< achow101>
moneyball: any opinions about it from the demo you saw?
< MarcoFalke>
moneyball: cfields: Elaborate, pls
< wumpus>
cfields can't be here today afaik
< jnewbery>
moneyball: can you summarise the strong feelings?
< fanquake>
Also agree.
< achow101>
strong feelings in a good or bad way?
< sipa>
bad.
< moneyball>
Concerns about increasing dependence on GitHub/Microsoft
< jonasschnelli>
Yes
< MarcoFalke>
Again, I don't think it gets worse. Also, we can use jonasschnelli's ci as a fallback (running in the background 24/7)
< fanquake>
jonasschnelli: do you want to update on the state of your CI? As an alternative?
< moneyball>
Which I agree is a valid point. My response was "What kind of productivity improvement over Travis would we need to see to want to move in that direction?" but I didn't really get a good answer. So, I'd pose that question here.
< jonasschnelli>
Update on the self hosted custom open source CI (bitcoinbuilds.org): it does now (since a week) successfully builds all PRs, mostly quicker than travis (though less envs). Integration with Github is doable and easy. But first lets see how it runs for at least 2 months.
< jonasschnelli>
Plan is to use the Github checks API when we think it has been proven to be reliable (2 month)
< wumpus>
moneyball: "no false positives"
< moneyball>
Another point made was concern that GitHub 3rd party API might suffer / degrade over time making 3rd party tools like Travis even worse (relative to GitHub CI)
< wumpus>
(or at least, neglible amount of, the problem with travis is false positives)
< sipa>
one point is that it seems to provide far more entry points than a normal CI does (it does much more automation of workflows, not just CI), and starting to depend on those seems like it would make it harder to move away (if ever needed)
< jonasschnelli>
good point
< MarcoFalke>
Yeah, good point.
< wumpus>
I wouldn't want to rely on it for automation of workflows
< fanquake>
Heh. We’ve already got plenty of GH “turned off” as well.
< moneyball>
I'm not sure if their announcement today means anyway can experiment with it not, but if not, then we have an invitation to experiment with it, if anyone is interested.
< wumpus>
just taking over what travis does now
< jonasschnelli>
They tend to mix auto-fix (code format correction and stuff) with CI which is indeed not only good
< sipa>
as long as it's a drop-in replacement of one CI for another, i agree there isn't much impact
< MarcoFalke>
We should only use it for the purpose of ci builds
< wumpus>
auto-fix ? no way
< MarcoFalke>
" You’re in the queue for the beta—we’ll let you know as soon as you have access. "
< wumpus>
that sounds realllllly scary
< wumpus>
damn
< sipa>
that's just an example of something you can configure
< sipa>
not a default thing
< MarcoFalke>
yes, all of the other stuff is just scary
< wumpus>
so now you CI doesn't only have false positives, it can introduce bugs and backdoors into your code !
< MarcoFalke>
Like self-driving cars for software development
< wumpus>
yea, lt's disable it, as fanquake says we have plenty of gh features disabled, what is one more … though it's something to watch
< wumpus>
yes, exactly
< luke-jr>
jonasschnelli: we've "tested" other CIs live - no reason not to do it with our own
< fanquake>
So is the resolution here to just wait until we can look at GH CI properly? Maybe test it in production alongside Travis?
< wumpus>
that sounds good to me
< jonasschnelli>
ack
< achow101>
ack
< luke-jr>
Does GH CI work with non-GH repos?
< MarcoFalke>
no
< achow101>
luke-jr: i highly doubt it
< wumpus>
luke-jr: only if you mirror them to github, I guess
< sipa>
luke-jr: embrace, extend, ...
< luke-jr>
I'm with cfields on that then…
< MarcoFalke>
luke-jr: Does travis work with non-GH repos?
< luke-jr>
I mean, if it's the only thing working, fine temporarily I guess, but I'd rather get away from GH dependency, not more entrenched
< wumpus>
luke-jr: definitely agree on that
< luke-jr>
MarcoFalke: not sure
< achow101>
I really thing we should just do both GH CI and bitcoinbuilds and just have them use the same config file
< jonasschnelli>
It looks like GitHub is taking over Git the same way gmail took over email... be aware
< moneyball>
does anyone want to test the GitHub CI now? let me know and I will introduce
< luke-jr>
achow101: +1
< luke-jr>
I wonder how long until there's some kind of standard for CIs
< jonasschnelli>
Nice centralized development functionality comes at a price
< achow101>
so we aren't entirely dependent on Github, but for individual developers, they can still run CI checks
< sipa>
achow101: i like that idea; it also forces us to keep the configuration to be compatible with non-GH features
< wumpus>
luke-jr: seems no, travis cannot use anything else than github, unless you have the enterprise version
< luke-jr>
moneyball: does it require permission to use?
< aj>
jonasschnelli: could test in production, but have it report "success" or "neutral" rather than "success" or "failure" maybe?
< sipa>
luke-jr: during the beta, yes
< luke-jr>
achow101: "make cichecks" would be nice :D
< achow101>
luke-jr: can't run on all of the platforms on one machine
< luke-jr>
achow101: why not? :\
< dongcarl>
qemu
< jonasschnelli>
aj: Yes. That would make sense.
< dongcarl>
so, perhaps _someone_ should try out the GitHub CI, and see if it's better than Travis, as a stop gap
< wumpus>
dongcarl: from my testing a few years ago, qemu-user works pretty well for the tests, at least if you stick to platforms with the same endianness
< luke-jr>
it sounds like bitcoinbuilds is further along than GitHub CI?
< MarcoFalke>
Could someone share a writeup of how to run the functional tests in qemu, pls?
< luke-jr>
MarcoFalke: write a shell script that runs the bitcoind bin, and export BITCOIND=/path/to/script
< achow101>
moneyball: you said we have an invitation to experiment with github CI?
< moneyball>
Yes
< achow101>
can we skip the queue?
< moneyball>
Presumably since they offered to let us use it a month ago
< dongcarl>
Is there a zero-effort Travis yml -> GH CI transition?
< sipa>
i doubt that
< MarcoFalke>
dongcarl: no
< dongcarl>
:-/
< dongcarl>
Why not stick to Travis till bitcoinbuilds is ready?
< MarcoFalke>
But the travis.yml mostly specifies the env, so it shouldn't be too hard either
< achow101>
dongcarl: because travis false positives too much
< luke-jr>
yeah, I imagine at least some of the scripts should be portable
< MarcoFalke>
I'd still like to run a ci with free minutes along of bitcoinbuilds
< jonasschnelli>
Me 2
< luke-jr>
"free minutes along of bitcoinbuilds"?
< achow101>
moneyball: can you ask them let some of us into the beta so we can try it out on our own repos first?
< MarcoFalke>
fee cpu time
< jonasschnelli>
I think centralized development tools are fine as long as there is an alternative running in parallel
< MarcoFalke>
*free
< luke-jr>
ah
< luke-jr>
I have lots of free ppc64le CPU time I think
< jonasschnelli>
The problem is lock-in, suddenly they charge for it or make it incompatible with your needs, ...and you'r screwed
< dongcarl>
jonasschnelli: Agreed.
< moneyball>
achow101: yes would you like access?
< achow101>
sure
< phantomcircuit>
achow101, travis is mostly hitting fp on resource exhaustion issues
< luke-jr>
moneyball: they can't just enable the entire repo +forks? :/
< moneyball>
i don't know
< sipa>
yeah, let's ask them how this works
< moneyball>
i will clarify with them
< achow101>
just enable it for anyone in the bitcoin and bitcoin-core orgs :)
< MarcoFalke>
Let's not enable the repo for now and keep testing in forks only
< jonasschnelli>
I'd also hope we consider some ethos and not further extend our reliance on github
< wumpus>
jonasschnelli: I agree, it's just, if we don't rely on anything further then switching from travis to github for CI doesn't make a difference, they're both centralized and githyb only
< fanquake>
wumpus: any other topics?
< wumpus>
nope
< jonasschnelli>
wumpus: There is maybe no technical difference,... but the signal to the community/world is different
< MarcoFalke>
Ok, that is a point I buy. They might say the GitHub ci is "approved by Bitcoin Core"
< wumpus>
Could someone share a writeup of how to run the functional tests in qemu <- I'll try if I get around to it, I think the most difficult part is setting up the faux-root filesystem for the target, though on some distros you can install that as package
< wumpus>
MarcoFalke: yes, that's scary
< jonasschnelli>
"Bitcoin Core implemente GitHub CI after talks with their CEO,... a week after they acted in massive censorship"
< jonasschnelli>
(I know I overstretch it)
< fanquake>
Then we’d all have to jump on Medium and explain our actions in an emoji filled post mortem.
< luke-jr>
might be a harder story to spin if we have our own CI at the same time
< achow101>
we could deploy both github CI and bitcoinbuilds simultaneously?
< wumpus>
haha way to go, fly ahead of the rumors in the meeting 😅
< luke-jr>
"We're migrating to our own CI, but helping GitHub test theirs too"
< MarcoFalke>
I'll experiment with the ci a bit in the coming days to see if it fits our use case. We can discuss more after everyone had a look
< jonasschnelli>
thanks MarcoFalke
< achow101>
+1
< wumpus>
yes, let's try that, maybe it's worse a match for our CI needs than travis is, then it's not even worth discussing further
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Aug 8 19:45:46 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)