Fixpoint

2024-05-04

#jwrd Logs for May 2024

Filed under: #jwrd logs, Logs — Jacob Welsh @ 03:30
Day changed to 2024-05-04
[03:30] jfw: http://jfxpt.com/2024/regrinding-busybox-archive-extraction-fixing-directory-timestamps-symlink-attacks-a-buffer-overflow-and-more/
Day changed to 2024-05-05
[21:07] dorion: http://dorion-mode.com/2024/05/coming-out-of-the-shadows-finally/
Day changed to 2024-05-06
[00:41] dorion: http://dorion-mode.com/2024/05/philosophy-is-laughter/
Day changed to 2024-05-08
[18:07] jfw: cruciform asked about SSD recommendations; for the Thinkpads we've pretty much been sticking with Samsung EVO, following the TMSR gossip - which AFAIK was indeed just gossip, no data.
[18:08] jfw: these however are consumer rather than 'enterprise' SSDs, for instance you're supposed to 'fstrim' them as they don't reserve capacity internally for wear leveling / garbage collection or however it works.
[18:10] jfw: there's this documented instance of a bit flip on disk on such a system but we don't know where it came from, possibly bad DRAM
[18:13] jfw: then this one is a clear failure by the SSD on a different machine
[18:14] jfw: I myself had this trouble but it seemed to implicate the apu1 rather than the drive
[18:17] jfw: here a PNY microSDHC card failing me in an unforgivable manner
[18:17] sourcerer: 2022-09-14 05:44:23 (#jwrd) jfw: apropos of those storage formatting observations, I've discovered a 16 GB PNY microSDHC card has failed dramatically, after a mere ~17 months of use in a car music player i.e. supposedly a read-mostly load.
Day changed to 2024-05-09
[00:39] jfw: but to sum up, there's enough anecdotes of failures that I don't view the samsung ssds as particularly holy; on the other hand they've often worked fine and we don't have enough data to make a statistical case either way, nor on the alternatives; personally I'm still fine with buying them
Day changed to 2024-05-14
[15:01] whaack: howdy
[15:02] whaack: dorion/jfw do you want to catch up through some vc medium in the near future?
[18:37] whaack: looks like somehow i managed to erase one of my wallets, it's as if i ran rm * in the wallet and then did gbw-save
[18:37] whaack: when i gbw-open he wallet ijust get an empty folder
[18:40] whaack: this is a big wtf moment for me. any way i may have accidently done this? i just dont know how the wallet is in this state
[20:42] dorion: whaack, sorry to hear about the troubles, I can vc sometime later this week. do you have a backup ?
[20:45] jfw: whaack, a catchup sounds good. re wallet, how about going through the steps manually - gpg decrypt it to get the tar file, then check what's in that (tar -tvf)
[21:01] whaack: jfw: gpg decrypt gives an empty file
[21:01] whaack: dorion: yes its backed up
[21:01] whaack: it's*
[21:18] jfw: whaack: empty as in zero bytes?
[21:19] jfw: (iirc a tar file with nothing in it will still have some zero-records)
[21:25] jfw: checking the gbw-save code it's actually done quite carefully so as to commit to disk before replacing the old file so there's nothing lost even in a system crash, nor will it proceed if the wallet tree to be saved doesn't exist, and the automatic tracking of paths through shell variables makes it pretty hard to mess up filenames or whatever (none of the commands but gbw-open and gbw-init even
[21:25] jfw: take any arguments)
[21:28] jfw: actually hmm, it's possible it would continue if the 'tar' fails, as its exit status is lost in the pipeline
[21:30] jfw: is it possible you manually deleted the whole dir in /tmp (not via gbw-discard or gbw-close) then did a save?
[21:30] whaack: jfw: im guessing that's what happened
[21:31] whaack: and yes 0 bytes
[21:45] jfw: ok, gnu tar produces a 10240 byte file but busybox tar produces a 0 byte file in this case. neither one does it silently though
[21:47] jfw: eg if I remove the /tmp/tmp.XXXXXX entirely, "tar: can't change directory to '/tmp/tmp.XXXXXX': No such file or directory", or if I remove only the wallet subdir, "tar: wallet: No such file or directory" "tar: error exit delayed from previous errors"
[21:49] jfw: so, this could be improved to prevent overwriting the encrypted file if the tree fails to exist entirely. but I also have to wonder why?!! would you do this? doesn't seem that much different from deleting the contents in which case it's indeed doing what you told it to
Day changed to 2024-05-15
[18:06] dorion waves from miami, about to high five jwm.
[18:18] jfw: what up jwm!
Day changed to 2024-05-17
[17:13] jfw: http://jfxpt.com/2024/poking-at-a-swarm-of-gnats/
Day changed to 2024-05-20
[16:02] whaack: jfw/dorion are either of you around today?
[16:07] dorion: yes.
[16:07] dorion: whaack, good morning.
[16:09] whaack: dorion: good morning!
[16:15] jfw: I'm around too
[17:22] whaack: jfw: cool, lmk if you and dorion want to connect over video
Day changed to 2024-05-22
[15:01] whaack: i'm testing reconnection, as that clearly has not been working
[15:03] whaack_: !E view-heigh
[15:03] testnzbtcexplorer: whaack_: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[15:08] whaack: !E view-height
[15:09] whaack: ah, problem is that the bot tries to reconnect before the server recognizes the dc, resulting in 'nick already in use' error and the bot choking on handling that
[15:14] whaack: the plot thickens, it does handle this eventually , but then does not rejoin the channel
[15:24] whaack_: !E view-height
[15:28] whaack: !E view-height
[15:58] whaack: !E view-height
[15:58] nzbtcexplorer: block_height: 844607
[15:58] nzbtcexplorer: mins_since_last_block: 15
[16:00] whaack: !e view-height
[16:00] btcexplorer: block_height: 844607
[16:00] btcexplorer: mins_since_last_block: -12
[16:39] whaack: reconnection should be good now
[16:39] whaack: !e help
[16:39] btcexplorer: whaack: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[16:40] whaack: !e push aeeefff
[16:40] btcexplorer: error: code: -22, message: tx decode failed
[16:40] whaack: pretty sure push should be working now as well
Day changed to 2024-05-23
[16:13] whaack: !E view-tx 420420 0
[16:13] nzbtcexplorer: http://jfxpt.com/paste/4fqz35quwh 1 of 1
[16:13] whaack: !E view-address 1CK6KHY6MHgYvmRQ4PAafKYDrg1ejbH1cE
[16:13] nzbtcexplorer: http://jfxpt.com/paste/wzj2r73qp8 1 of 1
[16:15] whaack: !e view-height
[16:15] btcexplorer: block_height: 844765
[16:15] btcexplorer: mins_since_last_block: 2
[16:15] whaack: !E view-height
[16:15] nzbtcexplorer: block_height: 844765
[16:15] nzbtcexplorer: mins_since_last_block: 30
[17:19] jfw: !E help
[17:19] nzbtcexplorer: jfw: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[17:19] jfw: !E view-raw-tx 420420 0
[17:19] nzbtcexplorer: raw_tx: 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1903446a0602650700749341231703ddb22d152f736c7573682f0000000001630b5b4b000000001976a9147c154ed1dc59609e3d26abb2df2ea3d587cd8c4188ac00000000
[17:19] jfw: !E push 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1903446a0602650700749341231703ddb22d152f736c7573682f0000000001630b5b4b000000001976a9147c154ed1dc59609e3d26abb2df2ea3d587cd8c4188ac00000000
[17:19] nzbtcexplorer: error: code: -27, message: tx already included in block
[17:22] jfw: !E push http://jfxpt.com/paste/nrdkeffstg
[17:22] nzbtcexplorer: error: code: -22, message: tx decode failed
[17:22] jfw: whaack: that might be an issue since rawtx won't always fit in an irc message
[17:23] jfw: looks like there's progress though
[17:23] jfw: does it deliberately not respond in PM?
[17:27] jfw: I suppose if it did then it would have access control to deal with since it wouldn't be pre-filtered by the channel voice modes
[18:01] whaack: it does not respond to dm
[18:01] whaack: !E http://jfxpt.com/paste/rzfhx4n6vn
[18:01] nzbtcexplorer: whaack: my valid commands are: src, uptime, version, help, view-height, view-address, view-utxos, view-balance, view-block, view-raw-block, view-tx, view-raw-tx, push
[18:02] whaack: !E push http://jfxpt.com/paste/rzfhx4n6vn
[18:02] nzbtcexplorer: error: code: -22, message: tx decode failed
[18:03] whaack: whaack: that might be an issue since rawtx won't always fit in an irc message << i'm confused by what you mean
[18:06] whaack: !E push http://jfxpt.com/paste/x7vb5d53r8
[18:06] nzbtcexplorer: error: code: -22, message: tx decode failed
[18:06] whaack: i see, it can't decode from pastes for some reason
[20:31] jfw: right, I just figured it wasn't implemented so tried to decode the link literally but dunno
Day changed to 2024-05-24
[14:23] whaack: !E push http://jfxpt.com/paste/x7vb5d53r8
[14:23] nzbtcexplorer: error: code: -27, message: tx already included in block
[14:26] whaack: !e push http://jfxpt.com/paste/x7vb5d53r8
[14:26] btcexplorer: error: code: -27, message: tx already included in block
[14:26] whaack: jfw: fixed
[17:39] jfw: nice!
Day changed to 2024-05-27
[14:35] whaack: !e view-height
[14:35] btcexplorer: block_height: 845385
[14:35] btcexplorer: mins_since_last_block: -24
[14:35] whaack: !E view-height
[14:35] nzbtcexplorer: block_height: 845385
[14:35] nzbtcexplorer: mins_since_last_block: 5
Day changed to 2024-05-28
[20:41] sstacks: greetings!
[20:41] dorion: welcome back sstacks ;-)
[20:41] sstacks: thank you! My cat has been more active than me
[20:42] dorion: jeje. well, up to you to flip the script.
[20:44] dorion: so what's new ?
[21:32] sstacks: Not much. Ive been resolving some personal issues and my father's as well. Hands full with those things and also the soon-arrival of baby Samantha. Medical appointments, courses, shopping, baby shower, etc.
[22:56] dorion: nice !
Day changed to 2024-05-29
[23:05] jfw: !w hi
[23:05] wotbot_test: Hello there, jfw
[23:06] jfw: !w help
[23:06] wotbot_test: I'm not very helpful yet.
[23:08] wotbot_test: But I do have a mind of my own. Or at least some strings to animate me.
Day changed to 2024-05-30
[16:24] dorion: wotbot_test, welcome !! looking forward to using you and helping you grow !
Day changed to 2024-05-31
[18:06] jfw: !w slowtest
[22:37] jfw: !w slowtest
[22:38] jfw: tricky bugs, silly bugs, bugs all around.
[22:38] jfw: !w slowtest
[22:38] wotbot_test: Sleeping 5 seconds...
[22:39] wotbot_test: done!
[22:39] jfw: !w slowtest
[22:39] wotbot_test: Sleeping 5 seconds...
[22:39] jfw: !w slowtest
[22:39] wotbot_test: Sleeping 5 seconds...
[22:39] jfw: !w slowtest
[22:39] wotbot_test: All workers busy (try again later).
[22:39] wotbot_test: done!
[22:39] wotbot_test: done!
[22:39] jfw: !w slowtest
[22:39] wotbot_test: Sleeping 5 seconds...
[22:39] jfw: !w slowtest
[22:39] wotbot_test: Sleeping 5 seconds...
[22:39] jfw: !w slowtest
[22:39] wotbot_test: All workers busy (try again later).
[22:39] wotbot_test: done!
[22:39] jfw: !w slowtest
[22:39] wotbot_test: Sleeping 5 seconds...
[22:39] wotbot_test: done!
[22:39] wotbot_test: done!
[22:39] jfw: sexy.
[22:43] jfw: so the bot can now chew on a configurable number of background tasks without going unresponsive and without queueing i.e. pretending it has capacity to accept a task without knowing when it might get started.
[22:45] jfw: this is a new general bot framework I'm cooking, web-of-trust commands are simply planned as the first application since it's what's most desired atm and not yet provided by the awk prototype.
[22:48] jfw: tasks can be dispatched to worker threads as seen above, or entirely separate processes, or messages can be relayed entirely from outside as illustrated earlier; perhaps for feed syndication or protocol bridging.
[22:50] jfw: or link archival results.
[23:02] jfw: had to trawl the literature a bit on condition variables and semaphores and such, ultimately just going with plain old locks (binary semaphores).
[23:05] jfw: the external message submission adds a small amount of undesired queueing, as it seems inevitable with either pipes or unix domain sockets and I did NOT want to go as deep as reinventing those with sysv shared memory or such.
[23:07] jfw: the bot controls its outbound flow rate to match the irc server so it won't get disconnected due to message flood.
[23:14] jfw: I reused some code from yrc, but that uses i/o multiplexing (select) while this uses true threads.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by MP-WP. Copyright Jacob Welsh.