Botched attempt from fresh install

izec@izec-iMac:~/zcash$ ./src/zcashd -daemon
Zcash server starting
izec@izec-iMac:~/zcash$ : Error loading block database.

Do you want to rebuild the block database now?
y
y: command not found
izec@izec-iMac:~/zcash$

I got the same result when I switched from running as root to user. It goes away if I run as root.

If it’s the same as I’ve seen before, your Zcash data directory (in the home directory of your user, if you were only using sudo and not actually logged in as root) will have incorrect ownership. To fix that you need to stop zcashd, run:

sudo chown USERNAME:USERNAME -R ~/.zcash ~/.zcash-params

and then start zcashd again as USERNAME.

3 Likes

Thanks, that worked. My previous problem of not getting much CPU or RAM usage while doing it as user is not present. BTW I seemed to get just as many coins with 1 thread and little CPU/RAM usage.

I spoke too soon. Running mining as user has dropped back it down to 1% CPU and 1% RAM. It was OK the first few times. Running with sudo never did that. The benchmark runs fine. I tried sudo again and it did not “fix” it this time, and used your line above again. It’s still not hardly working, but every now and then I glance over at “top”
and it’s working.

Check that you are connected to the network (lsof -i | grep zcashd should show a connection to the testnet node). Mining only happens if you are connected to peers.

Thats probably it because I see it suddenly work every now and then. Suddenly working with sudo might have been an accident. I wonder if my cable is spotty.

zcashd 2831 zawy 8u IPv6 52744 0t0 TCP ip6-localhost:18232 (LISTEN)
zcashd 2831 zawy 9u IPv4 52745 0t0 TCP localhost:18232 (LISTEN)
zcashd 2831 zawy 11u IPv6 52746 0t0 TCP *:18233 (LISTEN)
zcashd 2831 zawy 12u IPv4 52747 0t0 TCP *:18233 (LISTEN)

Maybe I should wait longer after I pkill the process because I sometimes get this:

Error: Cannot obtain a lock on data directory /home/scott/.zcash/testnet3. Bitcoin Core is probably already running.

Would changing zcash.conf during the process cause a problem?

I seem to be the only miner this morning. [edit: maybe it’s because they have a new release] After it finds a block and gets the coins, it takes 1 to 10 minutes to starting using more CPU and RAM again and no blocks are found. Then it might go to 25% CPU and 50 MB RAM with 8 threads for 6 minutes, still not finding any blocks. Then it jumps to 50% or 100% CPU and 400 MB RAM for 8 threads and finds a block in a minute or so and gets the coins.

I rebooted and after 20 minutes, 4 threads were showing a cumulative process time of 1 second (the TIME column in top and htop is sum core times). Then suddenly it increased to about 4 seconds per second, as it should, and a block + 10 coins was found in about 60 seconds of real time, and it stopped again. Now its sputtering up and down in multiples of 0%, 100%, or 200% CPU (0, 1, or 2 threads although the htop software threads show it to be an even split amoung them which I don’t understand) for 5 or 10 minutes so far with no blocks found.

Are you running Linux on bare metal or in a VM?
Also, you may want to run an update too since they released a new version last night:

I’m running ubuntu with dual boot on a PC. Thanks for letting me know about the update. I’m playing around with bash to monitor things.

I installed the update and it looks the same. The block number is not increasing unless I get the 10 coins. Is that right? Does that mean I’m the only one mining or that I’m a defunct node all to myself?

Sometimes it stops by itself, and always it stops after getting a block. Stays stopped 3 to 10 minutes.

Here are 10 second readings for 4 GB 1333 MHz, 4 threads, 4 core i5-750 CPU

Time, block, coin balance, total zcashd thread minutes, MB RAM/core, %CPU, %RAM

07/23/16 17:55:27 39327 2380 0 0 0 1
07/23/16 17:55:37 39327 2380 0 0 0 1
07/23/16 17:55:48 39327 2380 0 0 0 1
07/23/16 17:55:58 39327 2380 0 0 0 1
07/23/16 17:56:09 39327 2380 0 40 400 5
07/23/16 17:56:20 39327 2380 0 281 400 29
07/23/16 17:56:31 39327 2380 1 443 381 43
07/23/16 17:56:41 39327 2380 2 422 400 43
07/23/16 17:57:03 39327 2380 3 427 396 43
07/23/16 17:57:13 39327 2380 3 430 393 43
07/23/16 17:57:24 39327 2380 4 327 393 33
07/23/16 17:57:34 39328 2390 4 0 0 1
07/23/16 17:57:45 39328 2390 4 0 0 1
07/23/16 17:57:55 39328 2390 4 0 0 1
07/23/16 17:58:06 39328 2390 4 0 0 1
07/23/16 17:58:16 39328 2390 5 183 87 5
07/23/16 17:58:27 39328 2390 5 399 100 11
07/23/16 17:58:37 39328 2390 5 399 100 11
07/23/16 17:58:48 39328 2390 5 377 106 11
07/23/16 17:58:58 39328 2390 5 399 100 11
07/23/16 17:59:09 39328 2390 5 399 100 11
07/23/16 17:59:19 39328 2390 6 0 100 1
07/23/16 17:59:30 39329 2400 6 0 0 1
07/23/16 17:59:40 39329 2400 6 0 0 1
07/23/16 17:59:51 39329 2400 6 0 0 1
07/23/16 18:00:01 39329 2400 6 0 0 1
07/23/16 18:00:12 39329 2400 6 0 0 1
07/23/16 18:00:22 39329 2400 6 0 6 1
07/23/16 18:00:33 39329 2400 6 0 0 1
07/23/16 18:00:43 39329 2400 6 0 0 1
07/23/16 18:00:54 39329 2400 6 0 0 1
07/23/16 18:01:04 39329 2400 6 0 0 1
07/23/16 18:01:14 39329 2400 6 0 0 1
07/23/16 18:01:25 39329 2400 6 0 6 1
07/23/16 18:01:35 39329 2400 6 0 0 1
07/23/16 18:01:46 39329 2400 6 0 0 1
07/23/16 18:01:56 39329 2400 6 0 0 1
07/23/16 18:02:07 39329 2400 6 0 0 1
07/23/16 18:02:18 39329 2400 6 171 400 18
07/23/16 18:02:28 39329 2400 7 402 400 41
07/23/16 18:02:39 39329 2400 8 422 400 43
07/23/16 18:02:50 39329 2400 8 430 393 43
07/23/16 18:03:01 39329 2400 9 422 400 43
07/23/16 18:03:11 39329 2400 10 422 400 43
07/23/16 18:03:22 39329 2400 10 453 373 43
07/23/16 18:03:32 39330 2410 11 0 100 1
07/23/16 18:03:43 39330 2410 11 0 0 1
07/23/16 18:03:53 39330 2410 11 0 0 1
07/23/16 18:04:04 39330 2410 11 0 0 1
07/23/16 18:04:14 39330 2410 11 0 0 1
07/23/16 18:04:25 39330 2410 11 0 0 1
07/23/16 18:04:35 39330 2410 11 0 0 1
07/23/16 18:04:46 39330 2410 11 0 6 1
07/23/16 18:04:56 39330 2410 11 0 0 1
07/23/16 18:05:06 39330 2410 11 0 0 1
07/23/16 18:05:17 39330 2410 11 0 0 1