Hi i've been running a bitcoin node for the last two weeks and everything seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and used it in combination with lnd [0] (in testnet)
Please find the attached diff with two small improvements to the rc file: - add daemon_timeout=300. The daemon need time to shutdown successfully (syncing to disk). 300 sec. was choosen randomly but this value worked for me in several restarts. - remove pid_file. It works even without specifying it. With this, the port looks ok to me :) Cheer, Fabian [0] https://github.com/lightningnetwork/lnd Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < raf...@sizeofvoid.org>: > On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: > > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > > > On 2018-06-23 09:07:38, Thomas Frohwein <tfrohw...@fastmail.com> > wrote: > > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, tfrohw...@fastmail.com > wrote: > > > > > I think the blockchain size is a deterrent. I can test it when I'm > back from traveling in ~ 10 days and have access to additional GB on my > external drive, in case that helps. > > > > > > > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < > raf...@sizeofvoid.org> wrote: > > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > > > > > > > >It's not evil! It's NOT mining. ;) > > > > > > > > I installed it and tried to sync the 200GB blockchain to my external > HDD > > > > (because that's the only one that got this much space available). It > > > > synced fine for 1-2 days with the bitcoin-qt client, but then at > about > > > > 30-40% of the blockchain synced, it now starts throwing an error: > > > > > > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - > CAutoFile::read:fread failed: unspecified iostream_category error at > CBlockDiskPos(nFile=613, nPos=6513581) > > > > > > > > When this happens, the following lines appear in dmesg: > > > > > > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > > > > SENSE KEY: Media Error > > > > ASC/ASCQ: Unrecovered Read Error > > > > > > > > Fortunately, the drive still seems to be functional otherwise, can be > > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > > > > whenever mounting or unmounting said drive until I disconnect and > > > > reconnect the drive from the USB port. > > > > > > > > > > This is almost certainly a problem with the drive. I've had > > > several hard drives fail over the ~13 years or so I've been using > > > OpenBSD, and this is exactly the kind of error I see when the > > > drive is wearing out. > > > > > > The message means that the kernel could not read a sector on the > > > drive despite trying to do so. I've had drives continue to > > > otherwise work for years after throwing errors like that (though I > > > made sure to back them up and only used them as "scratch" drives). > > > Another time I had a drive fail within weeks of throwing an error > > > like that. > > > > > > If it's still under warranty, I'd recommend sending it in for > > > replacement. If it's not, I'd *highly* recommend backing up > > > anything on there to another drive. > > > > > > Sometimes, sectors can be "weak" and if you give the drive enough > > > time it will be able to read it, so if it can't be backed up > > > entirely, back up as much as you can, then let the drive sit for a > > > few days and try again. > > > > > > Some ports that may help: > > > sysutils/ddrescue > > > sysutils/testdisk > > > sysutils/e2fsprogs (for the "badblocks" program) > > > net/rsync (probably obvious, but still worth mentioning) > > > > > > Modern drives keep "spare sectors" in which to remap failing ones > > > like this, but they usually only do so when *writing* to the > > > sector, not when *reading* it. > > > > > > You could try backing up the drive, then writing zeros to the > > > entire drive with dd(1) to try to see if it helps. You could also > > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > > > > > > -n Use non-destructive read-write mode. By default only a non- > > > destructive read-only test is done. This option must > not be > > > combined with the -w option, as they are mutually > exclusive. > > > > > > "badblocks -n" will read all sectors on the drive and write back > > > the same data to the sector. If it's "weak", and the program can > > > manage to read the sector, the drive may then remap that sector to > > > a spare. > > > > > > But! How much do you really trust a drive that has started to > > > fail? Drives are cheap. Cheaper than they've ever been. If this > > > drive contains the only copy of family photos of your dearly > > > departed grandmother, are you willing to risk it? > > > > > > sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 > 0/direct fixed > > > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors > > > > > > I see a 3TB Western Digital My Book on a very popular online > > > retailer for only $89.99 USD with free shipping as I type this. > > > > > > Is the data on that drive worth more than that? Is the amount of > > > time you'd spend trying to squeeze a little more life out of the > > > drive worth it? How much do you value your free time? If you > > > enjoy tinkering with things like this and don't have valuable data > > > on it, it may be worth trying. If you'd rather spend that time > > > outside hiking or seeing friends and family, then it may be more > > > economical to just buy a new one. > > > > > > Ultimately, only you can decide. > > > > > > > I can't resume syncing the blockchain though because the error > appears > > > > again. > > > > > > > > > > While I'm here, I poked around bitcoin's manpage and found this: > > > > > > -prune=<n> > > > > > > Reduce storage requirements by enabling pruning > (deleting) of > > > old blocks. This allows the pruneblockchain RPC to be > called to > > > delete specific blocks, and enables automatic pruning of > old > > > blocks if a target size in MiB is provided. This mode is > > > incompatible with -txindex and -rescan. Warning: > Reverting this > > > setting requires re-downloading the entire blockchain. > (default: > > > 0 = disable pruning blocks, 1 = allow manual pruning via > RPC, > > > >550 = automatically prune block files to stay under the > > > specified target size in MiB) > > > > > > I have no idea if this only works *after* downloading the entire > > > blockchain or not, but it might be worth trying this option and > > > seeing if it will obviate the need for downloading 200+ GB of > > > data. > > > > > > Rafael: > > > If setting this option works out-of-the-box, it might be worth > > > making a note of it. Reading back through the thread, I see some > > > people saying that they couldn't test or use the port because they > > > don't have 200 GB of space for it. > > > > > > If it works, it might be worth adding a note to MESSAGE or a > > > README since this is probably going to be a common issue for most > > > people. > > > > > > > Not sure if this is a deficiency of the port or maybe the hard drive > > > > itself... > > > > > > > > > > As said above, it's almost certainly the drive. Please be sure to > > > back up anything important as soon as you can. > > > > > > -- > > > Bryan > > > > > > > Thanks Bryan Linton for the pruning hint. Thomas, I think, just like > > Bryan, your problem is a storage issue not an bitcoin(d). > > > > Please find attached a new tarball with following changes/improvements: > > > > - Update from bitcoin-0.16.0 to bitcoin-0.16.1 > > - Replace MESSAGE by README: > > -- RPC user and password > > -- Storage requirements > > > > Still waiting for a final okay > > For all fast cowboys, there is a quoting issue reported by David Hill. > Please change MAKE_FLAGS to: > > MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}" > CXXFLAGS="${CXXFLAGS}" >
