Show Idle (> d.) Chans
Results 1 ... 250 found in trilema for 'wedge' | →
mod6: I'll make a proper post on my blog, indeed. Just want to get this out for folks; now that there is a wedger tool out there, and it's been a number of days of reorccuring wedges.
mod6: Ok all of the logs are in http://www.mod6.net/wedger/
mod6: bvt: et, al. Still testing/debugging. Tried an experimental vpatch, didn't work. Going to make some changes and continue on. Here's the latest logs for the curious: http://www.mod6.net/wedger/mod6_wedger_test2.log http://www.mod6.net/wedger/trb_debug_wedgerpy_test2.log
mod6: bvt: et, al. Was able to use alf's wedger tool to replicate the problem. It took exactly 1 try. Here's my notes and debug.log (renamed) from the test: http://www.mod6.net/wedger/mod6_wedger_test1.log http://www.mod6.net/wedger/trb_debug_wedgerpy_test1.log
mod6: Happy to provide the 12G log if you want that, or a shorter one that shows on 22nd or 23rd my node starting, then getting wedged after wave.
mod6: When alf alerted about this wedge on the 22nd, I was quick to point out this wave of stuff that I don't typicaly see.
mod6: bvt: Yes, I experience exactly like you describe; right before 'wedge', incoming 30k or so of 'received getdata for: block' in debug.log.
bvt: anyone debug.log snapshots of wedge: did the period before wedge involve a large number of continous block requests?
bvt: well, the only thing i feel bad about in this situation is that for some time i was getting wedged in ~30 min, did not check the logs, assumed the DB corruption, rolled back to month-old chain snapshot without keeping the current
mp_en_viaje: bvt, don't feel too bad, this is a massive problem owing to the insanity of the gearbox involved. the vast majority of historically observed wedges were never reproduced
bvt: http://bvt-trace.net/2020/02/a-tiny-and-incomplete-trb-wedgetrace/#comment-139 - did some more debugging today, but cannot get a wedge when i do need it
bvt: mod6 or anyone else interested in this wedged bitcoind condition: do you want to get the coredump and the binary?
feedbot: http://bvt-trace.net/2020/02/a-tiny-and-incomplete-trb-wedgetrace/ << bvt's backtrace -- A tiny and incomplete TRB wedgetrace
mod6: Heads up to TRB users, seems that nodes have wedged on block 618406. A simple restart of TRB seemed to resolve it. Not sure on the cause yet. Will update with more information as I have it.
diana_coman: iirc he set it some timer because it was getting wedged on too many so now probably that works to... keep it up, lolz
asciilifeform: hmm, feedbot wedged ?
asciilifeform: BingoBoingo: american folx get so readily wedged in 'chitchat loop' , it boggles the mind.
asciilifeform: bvt: i still do not know whether socket 'was not closed, but wedged' somehow (in which case proggy oughta be made such as to find out, and close asap) or in fact closed but on acct of the idjit zombie-by-default thing, not reusable
snsabot: Logged on 2019-09-08 22:11:25 asciilifeform: ( then in principle dun gotta make new. but oughta test. nao q , how to reproduce wedged sockets, other than by playing fleanode lotto ? )
asciilifeform: ( then in principle dun gotta make new. but oughta test. nao q , how to reproduce wedged sockets, other than by playing fleanode lotto ? )
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-09-08#1935080 << seems like finally lobbes photographed that legendary ufo, the 'socket alive, but wedged tcp' state.
asciilifeform: BingoBoingo: quite likely, if you were to try an' reprocess that turd into a trb-edible block, you will end with a perma-wedged node.
snsabot: Logged on 2019-08-01 18:31:03 asciilifeform: at this pt, seems quite evident that someone is throwing around crafted wedge chains (i.e. mined after-the-fact , with backdated timestamp, going from older block) specifically to wedge syncing folx.
asciilifeform: ( wedge -- clock stops easily for days )
asciilifeform: aha, presumes 'wedged'
asciilifeform: if the 'silent wedge' effect actually exists (rather than , say, an artifact of trinque's async mechanisms) i expect it will eventually be found to wedge
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-22#1930066 << ftr i've yet to observe this 'silent wedge' effect in my bot (i.e. where the tcp pipe is 'alive' but not doing anyffin useful). tbf it is, what, only 3rd week of this bot.
asciilifeform: rright. wedge could easily be happening on acct of some idjit perl running on a crab usg clamped to cable in bermuda triangle...
asciilifeform: it's entirely conceivable tho that the wedge is on acct of a http://logs.nosuchlabs.com/log/ossasepia/2019-08-20#1000423 !
asciilifeform: trinque: it is interesting that the ssl thing gets wedged. if i had free hand might even try to find where -- could be a 0day in there, potentially
snsabot: Logged on 2019-08-16 20:56:57 trinque: http://logs.nosuchlabs.com/log/trilema/2019-08-11#1927727 << precisely right. what wedges, from my investigation here and elsewhere, is the seam between cl+ssl and openssl.
snsabot: Logged on 2019-08-11 22:34:33 asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-11#1927722 << i have a suspicion that trinque set it to cycle at 0hrs (in frustration re socket wedge ?)
trinque: http://logs.nosuchlabs.com/log/trilema/2019-08-11#1927727 << precisely right. what wedges, from my investigation here and elsewhere, is the seam between cl+ssl and openssl.
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-11#1927722 << i have a suspicion that trinque set it to cycle at 0hrs (in frustration re socket wedge ?)
asciilifeform: there is timeout on recv() so 'silent stall' also not wedges bot. at least in theory.
asciilifeform: at this pt, seems quite evident that someone is throwing around crafted wedge chains (i.e. mined after-the-fact , with backdated timestamp, going from older block) specifically to wedge syncing folx.
asciilifeform: at one pt i thought same re asciilifeform vs. trb . ( then mp_en_viaje unwedged me , he had bdb notes , '14 )
asciilifeform sees trinque's pov, many times was wedged on a problem where 'i have 95% of solution but for the remaining 5 -- ugliest turd ever seen' . but must agree with mp_en_viaje -- you can't get orig text from a hash, and can't vpatch if you aint got orig
a111: Logged on 2019-07-16 12:15 asciilifeform: http://btcbase.org/log/2019-07-16#1922497 << 'stays back' as in always 3-4 behind what someone else's (who's?) node height ? or perma-wedged at height h ?
asciilifeform: http://btcbase.org/log/2019-07-16#1922497 << 'stays back' as in always 3-4 behind what someone else's (who's?) node height ? or perma-wedged at height h ?
asciilifeform: ( to date -- no reports of a live specimen of constructed wedge chain, afaik )
asciilifeform: to round out this thrd : asciilifeform suspects that some unknown but nonzero % of 'perma-wedged noad' cases, are accounted for by adhoc attempts to carry out this experiment
a111: Logged on 2019-04-02 19:37 asciilifeform: http://btcbase.org/log/2019-04-02#1906563 << the 1 gotcha, is that if you (or peers) are wedged (genuinely wedged, on db grind; or peers wedged; or stuck on island in sea of prb; or... buncha documented , in log, cases ) then will get exactly 'where the fuck is my tx' errytime
a111: Logged on 2019-04-02 19:37 asciilifeform: http://btcbase.org/log/2019-04-02#1906563 << the 1 gotcha, is that if you (or peers) are wedged (genuinely wedged, on db grind; or peers wedged; or stuck on island in sea of prb; or... buncha documented , in log, cases ) then will get exactly 'where the fuck is my tx' errytime
asciilifeform: http://btcbase.org/log/2019-04-02#1906563 << the 1 gotcha, is that if you (or peers) are wedged (genuinely wedged, on db grind; or peers wedged; or stuck on island in sea of prb; or... buncha documented , in log, cases ) then will get exactly 'where the fuck is my tx' errytime
asciilifeform: hmm is the thing wedged or wat
mircea_popescu: dunno argument was "low hanging fruit". they wanna see what happens at high energy. the only way to see is to make. approximately situation of "when it comes to cooking, don't have to order out. alf has this method of making polenta, works well!" "and if i want lobster ?" "well then you gotta buy a lobster". getting indignant over how "wanting lobster only serves to drive an impossible wedge between budget and mariscos mercha
asciilifeform: trinque: deedbot wedged ?
mircea_popescu: trinque looks like something wedged her /sys , whatever partition that's on.
asciilifeform ~still~ frustratingly wedged with mircea_popescu's tube puzzle , turns out the 'S' constant for 35kV aint published anywhere, incl. the tube vendor ! and no info published re how to determine it from principles, seems like it gotta be measured by hand.
asciilifeform: typically gate wedged into metastability . difficult to calculate tho.
a111: Logged on 2019-02-12 23:36 asciilifeform: the avionics people seem to use it, but they (near as i was able to learn) dun kill tasks at all, and regard any detected wedge as a http://btcbase.org/log/2019-02-12#1895456 condition
asciilifeform: the avionics people seem to use it, but they (near as i was able to learn) dun kill tasks at all, and regard any detected wedge as a http://btcbase.org/log/2019-02-12#1895456 condition
asciilifeform: bvt: my reasoning is based on the docs description of how implemented. but certainly worth a test, if anyone can be arsed ( given the 'all loops gotta be doctored' thing, my understanding is that 'polled' proggy would choke if wedges inside a cppism )
asciilifeform: but also agree with mircea_popescu , you gotta have a way to halt a wedged device i/o at least.
a111: Logged on 2019-02-10 17:37 asciilifeform: will add to this also, that if yer thread is actually wedged, it will almost always be on acct of http://btcbase.org/log/2019-02-08#1893811 , i.e. waiting for a blocking unix i/o, and no matter what yer pthreads proggy is written in , c, ada, cobol, whatever, it will still become a zombie, cuz unix is retarded.
diana_coman: i.e. it "works" in the sense that it politely waits until that wedge task is kind enough to please come out of the loop so you can abort
diana_coman: model of wedged task was infinite loop, yes; and exit(0) was the only thing that did kill it but as you can see, that is C; imported in Ada, sure, but...C
asciilifeform: diana_coman: how did you model 'wedged task' ? ( i.e. what didja put in it ? infinite loop? or eternal i/o wait ? )
diana_coman: the issue at hand being that ADA doesn't kill ; and to add to this, note that in this case (i.e. some wedged task) it won't actually *finish* even when its checks fail; so that promise that "program will stop running if erroneous state" is at best mis-stated: no, it won't always stop, it might..wait to stop
asciilifeform: will add to this also, that if yer thread is actually wedged, it will almost always be on acct of http://btcbase.org/log/2019-02-08#1893811 , i.e. waiting for a blocking unix i/o, and no matter what yer pthreads proggy is written in , c, ada, cobol, whatever, it will still become a zombie, cuz unix is retarded.
asciilifeform: http://btcbase.org/log/2019-02-08#1893807 << the 1 concern there is blocking unix i/o calls, these can potentially wedge ( if not wrapped with appropriate timeout )
asciilifeform: it's a bitch tho, what you really want is to lose the wedge, rather than errything you keyed in the past xx min. hence asciilifeform's elaboration of the principle in http://www.loper-os.org/?p=215 .
asciilifeform: this is entirely correct, if you have a wedgeable subprocess in a correctly-written proggy, there is a catastrophic mistake and time to switch whole thing off and find where.
mircea_popescu: asciilifeform no, that's not the fucking question. the question is i don't have a wedgeable, and "somehow" the shit dun die when i say.
asciilifeform: mircea_popescu: the q is why you even ~have~ a wedgedeable -- i.e. having to be async-killed -- subprocess in yer proggy.
lobbes: http://btcbase.org/log/2018-11-29#1876124 << in other news, I figured out the cause of my node's sad: I'm an idjit and didn't set up proper periodic debug.log clearing (thing was 226 GB O-o). Truncating via a "truncate -s 0 /home/lobbes/.bitcoin/debug.log" did the trick; noad now is at 411015 (after being wedged at exactly 386827 for months).
asciilifeform: the latter is exactly the former, but perma-wedged -- rather like dwarfism
a111: Logged on 2018-11-29 22:50 asciilifeform: ( observe -- sans agression, the moar reliable is your hosting, the ~more~ certain your noad is to get perma-wedged, as it'll never reboot and never satisfy shitoshi's 'catch up only on cold boot' idjit condition.. )
asciilifeform: ( observe -- sans agression, the moar reliable is your hosting, the ~more~ certain your noad is to get perma-wedged, as it'll never reboot and never satisfy shitoshi's 'catch up only on cold boot' idjit condition.. )
asciilifeform: unrelatedly, to whom does trb noad 69.197.146.42 belong ?? it's been wedged for year+
asciilifeform: ( slime for instance routinely wedges it on some of my boxes )
a111: Logged on 2018-10-24 18:45 asciilifeform: mod6: in fact, and iirc i discussed this 2y or so ago in the l0g, by my current understanding of the reorg mechanism, it is possible to wedge ~any~ noad by throwing a specially- 'retro'-mined block with a higher work delta than the 'genuine' one at a particular point. then reorg dun trigger at all.
asciilifeform: the only practical defense against this is checkpointing, afaik. ( the prb folx tried to defend with 'orphanage', but with finite ram this does not actually solve the problem in the general case, simply ensures that different noades will wedge at different times )
asciilifeform: mod6: in fact, and iirc i discussed this 2y or so ago in the l0g, by my current understanding of the reorg mechanism, it is possible to wedge ~any~ noad by throwing a specially- 'retro'-mined block with a higher work delta than the 'genuine' one at a particular point. then reorg dun trigger at all.
asciilifeform: i.e. perma-wedge ?
asciilifeform: ( aside from rampant brokenness, in the years since gentoo author took 30 silvers from microshit and fucked it all ) would routinely get into circular wedges and fail in other 'interesting' ways
asciilifeform: http://btcbase.org/log/2018-10-06#1858813 << this, btw, is quite ordinary picture in recent ~decade of iron. given as even humble nic is nao a multicore arm thing, and has own kernel, and sometimes whole MB of internal state, fulla vendor shitware; so yes, can wedge .
asciilifeform: my parser wedged reading that ..
asciilifeform: btw if anyone wants to experimentally observe the zombie effect, can do it with ordinary gnu 'screen' -- when opened on a tty with blocking i/o, will routinely leave zombie turd instead of properly terminating, then hours later you find that tty is wedged, and discover 9 copies of 'screen' in process table.
asciilifeform: ( nobody's yet reported a wedged FG on the standard dd-powered test. )
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
asciilifeform: box is 1) wedged on boot , at 'booting kernel' or some unknowable later point 2) i cannot reset it from here , will need interactive help from BingoBoingo , and not once but several times ( if permitted to boot into trinque's cuntoo, and no worky, needs reset )
asciilifeform: because multilayer psychosis ultimately rooted in 'mother will provide me with what to suckle' wedge.
asciilifeform: so that 1 emacs can wedge and hang ALL of them ? nothx
mircea_popescu: these are eminently the sorts of problems of the stupid, whereby those who come after can't fucking discern what the everloving fuck were you thinking. however the empire managed to wedge them into stupid, through creating a hallucinatory "need for secrecy" or through "women get to choose, and you'll produce choices for them free of charge" or whatever nonsense -- the fact remains, here i sit, and they could've been the hitti
mircea_popescu: what's required of you is to explain ~how~ you processed sense data to end up in what looks from outside like wedges and thereby how to avoid it in future. even if it's a lot of explaining and fixing takes a lifetime, nevertheless, that's the process, and that's ~why~ "we're not x, we're y".
asciilifeform: there is no state and thereby no possibility of a wedge.
asciilifeform: hey trinque is the bozo ejector wedged or wat
ben_vulpes: node that mimisbrunnr is attached to is wedged in an interesting state, going to see about a dump with gdb tomorrow
ben_vulpes: and before you ask for logs from the wedged box -- it simply stopped writing logs. damndest thing.
ben_vulpes: asciilifeform: one interesting hiccup was that when i synced in vanilla "connect to wide net" mode, this new node somehow got stuck and also i think triggered some weirdo crash/wedge on another machine of mine with a raid array of rust that had until that moment been hanging at the tip of the spear, but when run with -connect to the self-same (restarted) node a) the rust caught back up within an hour and b)
asciilifeform: not with apu1+sage kit. it dun have a wedge state.
asciilifeform: the 'holy grail' is items which are demonstrably safe to operate continuously -- i.e. fsa with no wedge states. these are not so easy to achieve; FUCKGOATS is one example
asciilifeform: the wedge between cpu and ram clocks today would , i suspect, wipe out the performance difference for most problems
mircea_popescu: seems to me the tiny knolwedge afflicts he who should stfu and do a better job of world domination.
mircea_popescu: lmao alf got 50 comments from idiots. hang it there alfie, this isn't any kind of basis for judging blog. hackertards are just trying to drive wedge between man and man's tools.
mircea_popescu: asciilifeform i just want, from a strategic perspective, the tool whereby to be able to force a wedge among "website owners" and have them upgrade whether they want to or not, off the imperial tree.
asciilifeform: BingoBoingo: do you have a debug tail of this wedge ?
asciilifeform: phf: on one hand could be useful, on other -- one more piece for enemy to wedge shut or otherwise manipulate in the post
a111: Logged on 2017-08-06 03:01 asciilifeform: wedge at 168000 apparently.
a111: Logged on 2017-08-06 15:30 asciilifeform: BingoBoingo et al : to be very specific, the wedged box is running a press of mod6's 0.5.4-release, with the only change being phf's bsd patch linked yesterday.
asciilifeform: BingoBoingo et al : to be very specific, the wedged box is running a press of mod6's 0.5.4-release, with the only change being phf's bsd patch linked yesterday.
mircea_popescu: http://btcbase.org/log/2017-08-06#1694341 << the method is correct, but entirely unjustified effort for the possible payoff. nodes wedge because legacy bitcoin is shit, this sort of chrome polishing you propose is to be reserved for actually written code imo.
a111: Logged on 2017-08-06 03:43 phf: you replay to 167998, you then let it run till 168000 on the network. if it doesn't wedge with that setup, than you have two possibilities. it is either a heisenbug, or you need to replay to an earlier block, say 167000 and let that run on the wild network, etc.
mod6: take it easy. just asking as it was indicated to be source of previous 168k wedge issue.
phf: until you can actually reproduce the nature of locks patch vs. block (or whatever wedges)
phf: you replay to 167998, you then let it run till 168000 on the network. if it doesn't wedge with that setup, than you have two possibilities. it is either a heisenbug, or you need to replay to an earlier block, say 167000 and let that run on the wild network, etc.
phf: if it consistently wedges at 168000 across various machines and settings then it's not a question of wild sewage
phf: well, if i were approaching this, i'd replay to 167998 or so, setup a script to ensure that every time i start trb it starts from that state. i would then see if on forward play it would wedge. i would then investigate what is the nature of wedging, and slowly instrument the code along the various paths to tell me where exactly it decides to stop doing the right thing, etc.
a111: Logged on 2017-03-28 04:32 asciilifeform: mod6: imho manual knobs ~for unwedging~ are a fundamental mistake. nodes shouldn't be wedgeable, period. and the only use for a wedged node is to learn why it wedged and to make said scenario impossible in the future.
asciilifeform: phf: there was a bdb idiocy iirc that wedged at 168k
asciilifeform: ( i have 0 instances of wedged bring up on linux since mircea_popescu's bdb patch, in 30 or so shots on machines in various spots )
BingoBoingo addressed by restarting bitcoind on wedge
asciilifeform: wedge at 168000 apparently.
asciilifeform: it can be wedged apart with a relatively compact crowbar.
trinque: gotta wedge the broomstick at the right angle, can sit and sweep simultaneously!
asciilifeform: ^ lulzily, phuctor was wedged may 5 - may 10 on account of having been rebooted by unknown wreckers such that it left the werker lock file on.
TomServo: mod6: Sorry, nothing to report as yet. Node is still running, wedged, and untouched. Haven't had time to delve any deeper.
asciilifeform: mod6: imho manual knobs ~for unwedging~ are a fundamental mistake. nodes shouldn't be wedgeable, period. and the only use for a wedged node is to learn why it wedged and to make said scenario impossible in the future.
asciilifeform: mod6: to unwedge? nope. the tx index will be out of sync with the block db, and you get soup
asciilifeform: this could, potentially, account for some wedges observed in the wild. in theory.
mircea_popescu: not as such, no. but you can wedge it in through, eg, making it commit in batches
a111: Logged on 2017-01-26 02:33 mircea_popescu: this wedge will not prevail. i'll do without any milk, forever.
mod6: <+trinque> http://btcbase.org/log/2015-02-05#1008972 << mod6, is that why this patch did not make it in? << i don't think it was because of any such wedge. i think we held off because it was proposed that there might have been a better way to handle that through configuration files. it's all in the logs if you look in around the time that email was sent; december of '14.
asciilifeform: trinque: first q to ask in a wedge: 'has it SEEN the block?'
trinque has such a checkpoints-cauterized node wedged at that very block, will in fact study
asciilifeform: phf: most of today is re mircea_popescu showed a trb node that's been wedged, in a peculiar way, since july. but the l0g will still be there later.
asciilifeform: though mircea_popescu's wedge is preventable, what trb really ought to do is start sending http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 to all peers, starting with any 'wires' if present, whenever it goes for >1hr without a new block
asciilifeform: mircea_popescu: not necessarily, orphanage may or may not have unwedged it, as it discards old orphans when new appear.
shinohai: Whatever the outcome of the node wedge fix is, I need to write all this down as it may be a powerful tool to fuck with enemy in the future.
mircea_popescu: ie, you ~could~, theoretically, write such shit into a block that it wedges nodes.
asciilifeform: it sat there wedged ever since ?!
asciilifeform: aalso mircea_popescu looks like your node wedged in ... july ?! 2016
asciilifeform: pete_dushenski: mircea_popescu showed up with a bag of clues from a trb node that wedged some weeks ago. so now autopsy.
asciilifeform: trb's block push/pull mechanism is so retarded, that it is possible for a node to go for eons in a wedge, simply from never receiving the necessary unwedge blocks.
asciilifeform: (if it wedges and never speaks to honest node again, it'll stay wedged, noshit.jpg)
ben_vulpes: that node's not wedged but very far behind.
BingoBoingo: asciilifeform: It's where I wedged after pingpatch
asciilifeform: BingoBoingo: that is long past my wedgepoint
mircea_popescu: every dick and jane's expectation that "we did it reddit" is the faint echo of, man walked on the moon and generally speaking drove a wedge forcing a reevaluation of the celestial peerage. "as eternal as the nile flood" is no longer equal to "as eternal as the tide".
asciilifeform: but meanwhile, elsewhere in vast monkeystan, https://archive.is/lJxIm >> 'The indictment against Tverdokhlebov is based entirely on the years-old chats, with no hard information about specific thefts, suggesting that the feds are using it as a wedge to try and pry more evidence from Tverdokhlebov’s arrest and the search of his computers. Over government objections, a magistrate judge set Tverdokhlebov’s bail at $100,000 last week
mircea_popescu: asciilifeform that wedge will also not prevail.
mircea_popescu: this wedge will not prevail. i'll do without any milk, forever.
a111: Logged on 2017-01-03 20:48 mircea_popescu: in particular N.B should be "older overwrites newer" style ring buffer. of particular concern are situations where the buffer is set shorter than the longest reorg, in which case the node will wedge. TRB.N not accepting blocks with index lower than highest of B.B is for sure not feasible. "how many behind" should be an operator knob.
mircea_popescu: in particular N.B should be "older overwrites newer" style ring buffer. of particular concern are situations where the buffer is set shorter than the longest reorg, in which case the node will wedge. TRB.N not accepting blocks with index lower than highest of B.B is for sure not feasible. "how many behind" should be an operator knob.
asciilifeform: i've seriously considered reimplementing phuctor in this shape. as it is, it loses more from the slow writes idiotically queuing up, and the wedged reads that result, than it wins from fast structured queries.
asciilifeform: (that lead to same state - wedged node)
mod6: also, iirc around the same time there was much ado about the wedge @ 168`001 or whatever it was... but that turned out to be the database locking issue.
mircea_popescu: and i am entirely unconvinced by this "good at x" bs. nobody's "good at x". the "good at x" is nonsense of the ilk and period of "blind love", to try and help the wedge of who-equivalency into the trunk of reality.
asciilifeform: mircea_popescu: i dun see any unusual wedge
pete_dushenski: it's what i get for trying to wedge 'pygame' onto osxen box.
asciilifeform: and can be wedged apart.
asciilifeform: the pins in the lock end up wedged in it.
asciilifeform: reliably hard-wedged the nic, regardless of what os was running, or if any
asciilifeform: phf: nope. it wedges.
mircea_popescu: generally, thinking back to the whole "giant sitting in chair" discussion of supermarkets - the state always and everywhere tries to drive a wedge between you and its instrument. specifically, it tries to leverage the scale issue (see http://trilema.com/2009/de-ce-nu-mi-place-capitalismul/#selection-49.0-49.163 ) : you are many and impredictible ; its instruments could kill it.
asciilifeform: and without magic init from which, the thing won't boot, or will wedge itself deliberately half an hour post-warmup (in intel's case.)
mod6: <+trinque> I am wedged at 419554 too << did your trb continue on then too?
trinque: I am wedged at 419554 too
thestringpuller: i preserved the chain, and the bitcoind that built it. so what i'll do is get another disk, try to start from scratch with that build, and see if it wedges at the same place.
thestringpuller: why did it wedge there?
thestringpuller: ;;later tell mod6 node is still stuck even after restart. it's wedged at 414073
asciilifeform: they don't get wedged in minimax pits.
asciilifeform: in related nyooz, i discovered that one of my test trb boxen has been wedged, without any meaningful log noise whatsoever, for ~2wks
assbot: Logged on 13-03-2016 21:22:28; ben_vulpes: ascii_field: game theoretically permawedges obviously.
ben_vulpes: ascii_field: game theoretically permawedges obviously.
ascii_field: doesn't this permawedge?
assbot: Logged on 03-02-2016 16:52:56; ascii_butugychag: blackhole results when the worker thread (the one that handles nearly everything) is wedged
mod6: gernika: be sure to capture logs. we've seen wedges in the past, and they hvae some distinct tell tale signs in the logs.
gernika: asciilifeform: Since I've already shutdown the node, I can't answer your other questions at this time. I will once I've started it up again and it re-wedges (i.e. no new accepted blocks for 12+ hours)
mircea_popescu: <TomServo> I've finally got a node past the wedge, and there was much rejoicing << wd.
mod6: <+TomServo> I've finally got a node past the wedge, and there was much rejoicing << Rejoice!
TomServo: I've finally got a node past the wedge, and there was much rejoicing
ascii_butugychag: how to determine, without major surgery, what a wedged node is doing
ascii_butugychag: blackhole results when the worker thread (the one that handles nearly everything) is wedged
mod6: TomServo: hey! did you ever get unwedged?
mircea_popescu: it should unwedge in a coupla hours or so.
TomServo: It appears I'm somehow wedged at 252450 again. :( Just completed my first restart, so we'll see.
assbot: Logged on 26-01-2016 00:56:01; TomServo: My new node has been wedged at 252450 past several days (built using wiki instructions). Is this a curiosity at all? Or should I just retry? I certainly could've screwed something up.
TomServo: My new node has been wedged at 252450 past several days (built using wiki instructions). Is this a curiosity at all? Or should I just retry? I certainly could've screwed something up.
trinque: could wedge the magnetic doors open
mod6: indeed, Sir. our very own Max Wedge Hemi project.
mircea_popescu: mod6 reconfigures BDB to pass the wedge at block 252450 << remember that alf ? :D
mod6: And this statement is not accurate: ``With the “rm_checkpoints” patch, the wedge issue at Block 252450 was overcome.''
pete_dushenski: the two hours a week you can wedge into understanding bitcoin means that it'll be a decade before you sort out which was is up in the whole shebang
asciilifeform: it wedges out linux. to be replaced with - ubuntu et al.
mircea_popescu: it doesn't wedge linus from linux, it wedges linux from the usg world (or vice-versa)
asciilifeform: where was that mircea_popescu (?) article re: how a child learns that 'i can create!!1111!!' when he takes his first self-aware shit, and that many people wedge at this blockheight ?
mircea_popescu: "what, drive a wedge between the people and the governmentoregulating fruiting body ? WE OWN THE PEOPLE1!11!"
asciilifeform: a) a wedged node still pisses into the log b) log contains tx ids, many of which correspond to nothing that ends up in the blocks
pete_dushenski: i'd argue that this type of posturing ~does~ matter in the sense that it's a further wedge between ( ) boys and ( ) men
pete_dushenski: saw the best carved pumpkin this year : little pumpkin head wedged into a larger smashed out pumpkin head. sort of an 'alien' thing. very wd.
asciilifeform: i confess that not learning about mircea_popescucoin's db locks fix until ~after~ therealbitcoinw wedged to death was not fun.
asciilifeform: wedged ?
pete_dushenski: "Unsigned material will not be publicly acknolwedged in any manner for any reason, ever." << hear hear
mircea_popescu: "oh, our new fad diet is to only eat old car seats!!1 IT WORKS!!1". yeah, in the 1.7% of the population whose sticking point at that time happened to be a lack of X, which X is abundant in used car seats, it "helps", until the metabolism gets wedged into something else.
gernika: The node was not on the network, it was just eating from disk. It did not appear wedged, just processing one block after another.
ascii_field: let me guess, of the 3 weeks, most of the time was spent wedged ?
gernika: wedged - due to not having the patch yes
thestringpuller: If VPS is magically changing blockchain the client would wedge which it has not...
asciilifeform: ;;later tell mircea_popescu if you are running the item described in http://log.bitcoin-assets.com/?date=10-09-2015#1269180 this would handily explain why your node is so easily wedged. it lacks the db locks fix (and, on top of this, still stores fucking orphan tx, even)
asciilifeform: mod6: my box is not wedged.
mircea_popescu: asciilifeform i can actually unwedge it. i am satisfied the problem here is a subtle memory issue (not directly related to the bdb locks thing). specifically, to verify block 367851 bitcoind needs a certain amount of CONTIGUOUS memory. but it doesn't know this.
mircea_popescu: i just managed to reproduce the wedge AGAIN
mircea_popescu: asciilifeform are you wedged at 367850 ?
pete_dushenski: haha maybe an m156 wedges its way in there
asciilifeform: has never fallen behind, spontaneously, by so much as one block (the one notable exception was the day when the db locks thing wedged ~every~ honest node)
pete_dushenski: spiced 'captain wedgepants' and diet coke is a popular drink in these parts. with men !
mircea_popescu: they gotta import fucking what's that shit called, captain wedgepants
asciilifeform: it is only by a stroke of luck that therealbitcoin did not perma-wedge from corrupt db, also.
asciilifeform: 'if tree-walk wedges on account of your patch, blame yourself'
asciilifeform: mod6: no, understand, such a patch being submitted will wedge the machine.
asciilifeform: pete_dushenski: the wedge point would take about a week to reach, at typical pace, if starting from nil
pete_dushenski: hanbot: your stator build didn't get wedged even though you didn't add the asciilifeform_maxint_locks_corrected.patch ?
gernika: FYI OpenBSD w/o db patch wedged at 367850
assbot: Logged on 11-08-2015 08:56:46; BingoBoingo: When the last pre-0.8 wedge came through I suspected it was a BDB issue but alf was the one to euthanize it at the root.
BingoBoingo: When the last pre-0.8 wedge came through I suspected it was a BDB issue but alf was the one to euthanize it at the root.
TomServo: I'm late to the party, but thought I'd report my 0.5.3.1 is also wedged @ 367850.
asciilifeform: but also for debugging wedge states
ben_vulpes doesn't wedge frequently
ben_vulpes: coracle wedged firmly at 367850.
mircea_popescu: asciilifeform enemy is not able to wedge on demand.
asciilifeform: mircea_popescu: re: your earlier observation 'moar nodes!' - must determine if enemy is able to wedge on demand. because then it does not particularly matter how many of us there are.
asciilifeform: kill-9, restarted, now wedged at 'Loading block index...'
asciilifeform: dulap ~STILL~ wedged
ben_vulpes: asciilifeform: my coracle's been wedged at 367850 since last night, even with the new db locks config. last 500 lines of debug.log: http://dpaste.com/1XB21DH.txt , please let me know if more would be useful
asciilifeform: eh no. my nodez ran from ignition until wedge day
asciilifeform: recall, flagship nodes were wedged
BingoBoingo: So, since everyone is apparently looking at db behavior in BTC now... A few hours ago I reset my BIOS clock back a full day. Rightly It refused to acknowledge blocks more than two hours into the future. Then I reset clock to be right. Client refused to correct itself all at once. However many block it scooped up in the verifying databases phase seems to be as far as it got before permawedgeing. Killing and restating fixed issue. B
assbot: New Per Block Transaction Highs Wedge Some Nodes: Patch Available | Qntra ... ( http://bit.ly/1IBUueb )
assbot: New Per Block Transaction Highs Wedge Some Nodes: Patch Available | Qntra ... ( http://bit.ly/1IBTiHF )
asciilifeform: dulap unwedged.
BingoBoingo: Unwedged
asciilifeform: anyone who is wedged - straight there.
BingoBoingo: electawedge
mircea_popescu: no, it was wedged to allow study of the wedge point.
asciilifeform: mircea_popescu: i thought it was perma-wedged
asciilifeform: get stuck in one, and all threads perma-wedge
asciilifeform: another interesting discovery: when the 'socket closed' wedge state is in progress, 'getinfo' rpc wedges
BingoBoingo: punkman: Unwedged 0.7-ish stator still isn't anywhere near this sync'd yet
asciilifeform: they're all firmly wedged
punkman: BingoBoingo: so you have an unwedged 0.5.3?
punkman: so they got wedged pretty bad?
BingoBoingo: trinque: It seemed like a safer number than the one that wedged before
BingoBoingo: Seems likely. I'm just wondering what this crud is that wedged just now.
| →
Random(trilema) | Download hourly DB snapshot | Get Source Code