[ mining os ] nvoc - page 112. | Bitcointalksearch.org

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: crazydane on December 11, 2017, 03:14:50 PM

Quote from: Stubo on December 11, 2017, 03:02:15 PM

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switched back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:09 PM) (Detached)
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:09 PM) (Detached)
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.

Replace the complete XMR part in 3main with this and test :

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]
then
HCD='/home/m1/cpuOPT/cpuminer'
XMRADDR="$XMR_ADDRESS.$XMR_WORKER"
running=$(ps -ef | awk '$NF~"cpuminer" {print $2}')
echo ""
echo ""
echo "LAUNCHING: plusCPU"
if [ "$running" == "" ]
then
guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
echo ""
echo "plusCPU process in guake terminal Tab (f12)"
echo ""
running=""
fi
fi

Stubo

member

Activity: 224

Merit: 13

Quote from: leenoox on December 11, 2017, 03:19:49 PM

Quote from: crazydane on December 11, 2017, 03:14:50 PM

Quote from: Stubo on December 11, 2017, 03:02:15 PM

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switch back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:06 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.

I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight

I think I may have found another problem we haven't even seen yet because of the existing one. In 3main, there is this if statement that determines if 0main is to be executed:

Code:

running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
   if [ "$running" == "" ]
   then
   if [ $LOCALorREMOTE == "REMOTE" ]
   then
   bash /home/m1/0miner

So if plusCPU was running when it gets to this point in the code [that launches 0miner], $running would be set to the PID of the plusCPU miner (cpuminer) and if we are REMOTE (grep -i screen). The IF following that code would not launch 0miner. Eventually, if the watchdog was running, it would see low GPU utilization and attempt to launch 3main again, and again.

So I think that running line should exclude cpuminer. Something like this:

Code:

running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: leenoox on December 11, 2017, 03:19:49 PM

Quote from: crazydane on December 11, 2017, 03:14:50 PM

Quote from: Stubo on December 11, 2017, 03:02:15 PM

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switch back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:06 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.

I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight

I dont see any extra .. do you ?

Code:

if [ $LOCALorREMOTE == "LOCAL" ]
then
guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT
fi

leenoox

full member

Activity: 200

Merit: 101

Quote from: crazydane on December 11, 2017, 03:14:50 PM

Quote from: Stubo on December 11, 2017, 03:02:15 PM

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switch back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:07 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
2076.temp (12/11/2017 03:12:06 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:10 PM) (Detached)
2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
2186.miner (12/11/2017 03:12:09 PM) (Detached)
2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.

I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight

crazydane

full member

Activity: 558

Merit: 194

Quote from: Stubo on December 11, 2017, 03:02:15 PM

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switched back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
   2044.plusCPU (12/11/2017 03:12:03 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:09 PM) (Detached)
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:10 PM) (Detached)
   2076.temp (12/11/2017 03:12:07 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
   2186.miner (12/11/2017 03:12:09 PM) (Detached)
   2076.temp (12/11/2017 03:12:06 PM) (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.

Stubo

member

Activity: 224

Merit: 13

Quote from: crazydane on December 11, 2017, 02:21:32 PM

Ah yes. Sorry guys. My bad. I forgot to change those back to CUSTOM and $HOSTNAME after running the update script.

So only outstanding issues that I have now are related to plusCPU;

1. Only works in LOCAL, not REMOTE
2. Password being passed is x and not MINER_PWD

I have:

0miner

Code:

"pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",

"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,

1bash

Code:

# XMR : if plusCPU is "YES" replace with your XMR info ##
XMR_WORKER=$WORKERNAME
XMR_ADDRESS="crazydane"
XMR_POOL="us-east.cryptonight-hub.miningpoolhub.com"
XMR_PORT="20580"

3main

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]
then
HCD='/home/m1/cpuOPT/cpuminer'
XMRADDR="$XMR_ADDRESS.$XMR_WORKER"
echo ""
echo ""
echo "LAUNCHING: plusCPU"
if [[ `ps -ef |grep cpuminer |grep -v grep |wc -l` -eq 0 ]]
then
if [ $LOCALorREMOTE == "LOCAL" ]
then
guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT
fi
echo ""
echo "plusCPU process in guake terminal Tab (f12)"
echo ""
running=""
fi

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: joshuajones02 on December 11, 2017, 02:55:28 PM

Quote from: papampi on December 11, 2017, 02:48:07 PM

Quote from: joshuajones02 on December 11, 2017, 02:25:08 PM

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001" # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

Thanks, but did you mean can't? lol. Guess maybe its just coincidental.

lol ... yes my typos as always ...

joshuajones02

full member

Activity: 210

Merit: 100

Quote from: papampi on December 11, 2017, 02:48:07 PM

Quote from: joshuajones02 on December 11, 2017, 02:25:08 PM

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001" # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

Thanks, but did you mean can't? lol. Guess maybe its just coincidental.

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: joshuajones02 on December 11, 2017, 02:25:08 PM

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001" # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can not be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

joshuajones02

full member

Activity: 210

Merit: 100

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001" # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

crazydane

full member

Activity: 558

Merit: 194

Ah yes. Sorry guys. My bad. I forgot to change those back to CUSTOM and $HOSTNAME after running the update script.

So only outstanding issues that I have now are related to plusCPU;

1. Only works in LOCAL, not REMOTE
2. Password being passed is x and not MINER_PWD

I have:

0miner

Code:

"pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",

"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,

1bash

Code:

# XMR : if plusCPU is "YES" replace with your XMR info ##
XMR_WORKER=$WORKERNAME
XMR_ADDRESS="crazydane"
XMR_POOL="us-east.cryptonight-hub.miningpoolhub.com"
XMR_PORT="20580"

3main

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]
then
HCD='/home/m1/cpuOPT/cpuminer'
XMRADDR="$XMR_ADDRESS.$XMR_WORKER"
echo ""
echo ""
echo "LAUNCHING: plusCPU"
if [[ `ps -ef |grep cpuminer |grep -v grep |wc -l` -eq 0 ]]
then
if [ $LOCALorREMOTE == "LOCAL" ]
then
guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT
fi
echo ""
echo "plusCPU process in guake terminal Tab (f12)"
echo ""
running=""
fi

Stubo

member

Activity: 224

Merit: 13

Quote from: crazydane on December 11, 2017, 01:30:41 PM

I just edited my previous reply. It would appear that host name is not being passed either. Instead the last octet of the ip address is being used.

See if you have these set properly in 1bash:

Code:

AUTO_WORKERNAME="CUSTOM" # HOST or MAC or CUSTOM # Use HOST IP address or network card MAC address or CUSTOM name workername

CUSTOM_WORKERNAME=$HOSTNAME # If AUTO_WORKERNAME="CUSTOM" enter your desired workername here

I suspect AUTO_WORKERNAME is set to HOST.

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: crazydane on December 11, 2017, 01:30:41 PM

I just edited my previous reply. It would appear that host name is not being passed either. Instead the last octet of the ip address is being used.

From 1bash:

Code:

AUTO_WORKERNAME="HOST" # HOST or MAC or CUSTOM # Use HOST IP address or network card MAC address or CUSTOM name workername

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: EvgeniX on December 11, 2017, 11:20:51 AM

Quote from: joshuajones02 on December 11, 2017, 11:03:16 AM

Quote from: EvgeniX on December 11, 2017, 10:36:35 AM

who can share their experience with which more profitable mining best coin in current moment or mining one?

This isn't the right thread for that question man, better luck in other threads, especially those that are covering the GPU you are using as there are many different variables that determine this question

Yes and NO

looks like most people who use WTM is using nvOC, thats why I ask here if any one can share their experience

If by people using wtm you mean wtm auto switch then the answer is simple ...

Add the coins you see they are profitable in wtm web page or coins you like more to wtm section in 1bash :

Code:

WTM_AUTO_SWITCH_COINS="ZEC;ZEN;ETH;BTG;FTC;MONA;VTC;;TZC"

Set WTM_AUTO_SWITCH=YES
and carry on mining ...

crazydane

full member

Activity: 558

Merit: 194

Quote from: papampi on December 11, 2017, 01:23:39 PM

Change from :

Code:

guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

To :

Code:

guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT

There is also some settings in 0miner, open 0miner
in xmr section, change

Code:

"pool_password" : "x",

to

Code:

"pool_password" : "MINER_PWD ",

Made the above changes except I used "MINER_PWD" instead of "MINER_PWD " and restarted, but I'm still getting:

Code:

/home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10

And:

Code:

/home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21

So password is being passed for GPU miner, but not CPU miner.

And for both miners, the last octet of the ip addresses is being passed instead of the hostname.

crazydane

full member

Activity: 558

Merit: 194

I just edited my previous reply. It would appear that host name is not being passed either. Instead the last octet of the ip address is being used.

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: crazydane on December 11, 2017, 12:52:23 PM

When I do a control-c to kill it, watchdog never attempts to restart it. I also never get email notifications that it quit.

Watchdog has always been only checking GPU

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: crazydane on December 11, 2017, 12:52:23 PM

Quote from: papampi on December 11, 2017, 12:36:58 PM

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

I don't have a local display attached, I run remote only. I captured the command that executes and when I execute it from a ssh session, the miner works fine.

Code:

m1@miner06:~$ /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10

   ********** cpuminer-opt 3.6.3 ***********
   A CPU miner with multi algo support and optimized for CPUs
   with AES_NI and AVX extensions.
   BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
   Forked from TPruvot's cpuminer-multi with credits
   to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
   Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
CPU features: SSE2 AES AVX AVX2
SW built on May 18 2017 with GCC 5.4.0
SW features: SSE2
Algo features: SSE2 AES
Start mining with SSE2

[2017-12-11 12:45:25] Starting Stratum on stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580
[2017-12-11 12:45:25] 10 miner threads started, using 'cryptonight' algorithm.
[2017-12-11 12:45:26] Stratum difficulty set to 500054
[2017-12-11 12:45:29] CPU #4: 66 H, 28.78 H/s
[2017-12-11 12:45:30] CPU #5: 66 H, 28.43 H/s
[2017-12-11 12:45:31] CPU #0: 66 H, 19.10 H/s
[2017-12-11 12:45:31] CPU #1: 66 H, 18.81 H/s
[2017-12-11 12:45:31] CPU #2: 66 H, 18.74 H/s
[2017-12-11 12:45:31] CPU #3: 66 H, 18.53 H/s
[2017-12-11 12:45:31] CPU #7: 66 H, 18.11 H/s
[2017-12-11 12:45:31] CPU #8: 66 H, 17.94 H/s
[2017-12-11 12:45:31] CPU #9: 66 H, 17.73 H/s
[2017-12-11 12:45:31] CPU #6: 66 H, 15.76 H/s
[2017-12-11 12:45:44] CPU #8: 250 H, 18.93 H/s
[2017-12-11 12:45:44] CPU #0: 267 H, 19.87 H/s
[2017-12-11 12:45:44] CPU #3: 262 H, 19.65 H/s
[2017-12-11 12:45:44] CPU #1: 264 H, 19.71 H/s
[2017-12-11 12:45:44] CPU #4: 447 H, 30.59 H/s
[2017-12-11 12:45:44] CPU #9: 250 H, 18.96 H/s
[2017-12-11 12:45:44] CPU #5: 441 H, 30.21 H/s
[2017-12-11 12:45:44] CPU #2: 263 H, 19.62 H/s
[2017-12-11 12:45:44] CPU #6: 208 H, 16.32 H/s
[2017-12-11 12:45:44] CPU #7: 252 H, 18.97 H/s
[2017-12-11 12:46:39] Stratum difficulty set to 350009
[2017-12-11 12:46:39] CPU #8: 1046 H, 18.90 H/s
[2017-12-11 12:46:39] CPU #2: 1087 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #7: 1048 H, 18.94 H/s
[2017-12-11 12:46:39] CPU #0: 1099 H, 19.85 H/s
[2017-12-11 12:46:39] CPU #5: 1673 H, 30.23 H/s
[2017-12-11 12:46:39] CPU #4: 1693 H, 30.58 H/s
[2017-12-11 12:46:39] CPU #9: 1046 H, 18.89 H/s
[2017-12-11 12:46:39] CPU #3: 1088 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #1: 1090 H, 19.68 H/s
[2017-12-11 12:46:40] CPU #6: 905 H, 16.34 H/s
[2017-12-11 12:47:35] Stratum difficulty set to 245006
[2017-12-11 12:47:35] CPU #1: 1097 H, 19.75 H/s
[2017-12-11 12:47:35] CPU #7: 1055 H, 18.98 H/s
[2017-12-11 12:47:35] CPU #0: 1108 H, 19.94 H/s
[2017-12-11 12:47:35] CPU #9: 1054 H, 18.96 H/s
[2017-12-11 12:47:35] CPU #2: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #4: 1702 H, 30.62 H/s
[2017-12-11 12:47:35] CPU #5: 1685 H, 30.31 H/s
[2017-12-11 12:47:35] CPU #6: 903 H, 16.26 H/s
[2017-12-11 12:47:35] CPU #3: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #8: 1055 H, 18.97 H/s
[2017-12-11 12:48:31] Stratum difficulty set to 171503
[2017-12-11 12:48:31] CPU #8: 1055 H, 19.01 H/s
[2017-12-11 12:48:31] CPU #0: 1109 H, 19.97 H/s
[2017-12-11 12:48:31] CPU #2: 1097 H, 19.76 H/s
[2017-12-11 12:48:31] CPU #6: 906 H, 16.32 H/s
[2017-12-11 12:48:31] CPU #9: 1056 H, 19.02 H/s
[2017-12-11 12:48:31] CPU #4: 1702 H, 30.65 H/s
[2017-12-11 12:48:31] CPU #5: 1685 H, 30.34 H/s
[2017-12-11 12:48:31] CPU #7: 1057 H, 19.03 H/s
[2017-12-11 12:48:31] CPU #3: 1097 H, 19.75 H/s
[2017-12-11 12:48:31] CPU #1: 1099 H, 19.78 H/s
[2017-12-11 12:48:46] CPU #2: 296 H, 19.58 H/s
[2017-12-11 12:48:46] CPU #9: 284 H, 18.79 H/s
[2017-12-11 12:48:46] CPU #8: 285 H, 18.81 H/s
[2017-12-11 12:48:46] CPU #4: 462 H, 30.52 H/s
[2017-12-11 12:48:46] CPU #5: 457 H, 30.20 H/s
[2017-12-11 12:48:46] CPU #3: 296 H, 19.57 H/s
[2017-12-11 12:48:46] CPU #0: 301 H, 19.84 H/s
[2017-12-11 12:48:46] CPU #1: 297 H, 19.63 H/s
[2017-12-11 12:48:46] CPU #7: 286 H, 18.89 H/s
[2017-12-11 12:48:46] CPU #6: 246 H, 16.22 H/s

When I do a control-c to kill it, watchdog never attempts to restart it. I also never get email notifications that it quit.

So for now, I'm just running that launch command from the ssh window and things are running smoothly again like on 19-1.4

EDIT: That launch command is showing -u crazydate.115 where it should be -u crazydane.solar

mph ignores the password, but is should be passing along the MINER_PWD set in 1bash should it not?

In my case, that would be:

Code:

# For zpool use MINER_PWD="$WORKERNAME,c=btc"
MINER_PWD="solar" # Set the miner password. Default: x

It just so happens that the ip address I have mapped to miner06 is 10.0.1.115. Coincidence?

OK, another bug in 3main, but I think its irrelevant as mph says it doesnt check the worker password
Password is missing from 3main launch command

Change from :

Code:

guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

To :

Code:

guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT

There is also some settings in 0miner, open 0miner
in xmr section, change

Code:

"pool_password" : "x",

to

Code:

"pool_password" : "MINER_PWD ",

Also can you post contents of this file after you start miner if it fails:

Code:

/home/m1/xmr/stakGPU/bin/config.txt

crazydane

full member

Activity: 558

Merit: 194

Quote from: papampi on December 11, 2017, 12:36:58 PM

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

I don't have a local display attached, I run remote only. I captured the command that executes and when I execute it from a ssh session, the miner works fine.

Code:

m1@miner06:~$ /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10

   ********** cpuminer-opt 3.6.3 ***********
   A CPU miner with multi algo support and optimized for CPUs
   with AES_NI and AVX extensions.
   BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
   Forked from TPruvot's cpuminer-multi with credits
   to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
   Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
CPU features: SSE2 AES AVX AVX2
SW built on May 18 2017 with GCC 5.4.0
SW features: SSE2
Algo features: SSE2 AES
Start mining with SSE2

[2017-12-11 12:45:25] Starting Stratum on stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580
[2017-12-11 12:45:25] 10 miner threads started, using 'cryptonight' algorithm.
[2017-12-11 12:45:26] Stratum difficulty set to 500054
[2017-12-11 12:45:29] CPU #4: 66 H, 28.78 H/s
[2017-12-11 12:45:30] CPU #5: 66 H, 28.43 H/s
[2017-12-11 12:45:31] CPU #0: 66 H, 19.10 H/s
[2017-12-11 12:45:31] CPU #1: 66 H, 18.81 H/s
[2017-12-11 12:45:31] CPU #2: 66 H, 18.74 H/s
[2017-12-11 12:45:31] CPU #3: 66 H, 18.53 H/s
[2017-12-11 12:45:31] CPU #7: 66 H, 18.11 H/s
[2017-12-11 12:45:31] CPU #8: 66 H, 17.94 H/s
[2017-12-11 12:45:31] CPU #9: 66 H, 17.73 H/s
[2017-12-11 12:45:31] CPU #6: 66 H, 15.76 H/s
[2017-12-11 12:45:44] CPU #8: 250 H, 18.93 H/s
[2017-12-11 12:45:44] CPU #0: 267 H, 19.87 H/s
[2017-12-11 12:45:44] CPU #3: 262 H, 19.65 H/s
[2017-12-11 12:45:44] CPU #1: 264 H, 19.71 H/s
[2017-12-11 12:45:44] CPU #4: 447 H, 30.59 H/s
[2017-12-11 12:45:44] CPU #9: 250 H, 18.96 H/s
[2017-12-11 12:45:44] CPU #5: 441 H, 30.21 H/s
[2017-12-11 12:45:44] CPU #2: 263 H, 19.62 H/s
[2017-12-11 12:45:44] CPU #6: 208 H, 16.32 H/s
[2017-12-11 12:45:44] CPU #7: 252 H, 18.97 H/s
[2017-12-11 12:46:39] Stratum difficulty set to 350009
[2017-12-11 12:46:39] CPU #8: 1046 H, 18.90 H/s
[2017-12-11 12:46:39] CPU #2: 1087 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #7: 1048 H, 18.94 H/s
[2017-12-11 12:46:39] CPU #0: 1099 H, 19.85 H/s
[2017-12-11 12:46:39] CPU #5: 1673 H, 30.23 H/s
[2017-12-11 12:46:39] CPU #4: 1693 H, 30.58 H/s
[2017-12-11 12:46:39] CPU #9: 1046 H, 18.89 H/s
[2017-12-11 12:46:39] CPU #3: 1088 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #1: 1090 H, 19.68 H/s
[2017-12-11 12:46:40] CPU #6: 905 H, 16.34 H/s
[2017-12-11 12:47:35] Stratum difficulty set to 245006
[2017-12-11 12:47:35] CPU #1: 1097 H, 19.75 H/s
[2017-12-11 12:47:35] CPU #7: 1055 H, 18.98 H/s
[2017-12-11 12:47:35] CPU #0: 1108 H, 19.94 H/s
[2017-12-11 12:47:35] CPU #9: 1054 H, 18.96 H/s
[2017-12-11 12:47:35] CPU #2: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #4: 1702 H, 30.62 H/s
[2017-12-11 12:47:35] CPU #5: 1685 H, 30.31 H/s
[2017-12-11 12:47:35] CPU #6: 903 H, 16.26 H/s
[2017-12-11 12:47:35] CPU #3: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #8: 1055 H, 18.97 H/s
[2017-12-11 12:48:31] Stratum difficulty set to 171503
[2017-12-11 12:48:31] CPU #8: 1055 H, 19.01 H/s
[2017-12-11 12:48:31] CPU #0: 1109 H, 19.97 H/s
[2017-12-11 12:48:31] CPU #2: 1097 H, 19.76 H/s
[2017-12-11 12:48:31] CPU #6: 906 H, 16.32 H/s
[2017-12-11 12:48:31] CPU #9: 1056 H, 19.02 H/s
[2017-12-11 12:48:31] CPU #4: 1702 H, 30.65 H/s
[2017-12-11 12:48:31] CPU #5: 1685 H, 30.34 H/s
[2017-12-11 12:48:31] CPU #7: 1057 H, 19.03 H/s
[2017-12-11 12:48:31] CPU #3: 1097 H, 19.75 H/s
[2017-12-11 12:48:31] CPU #1: 1099 H, 19.78 H/s
[2017-12-11 12:48:46] CPU #2: 296 H, 19.58 H/s
[2017-12-11 12:48:46] CPU #9: 284 H, 18.79 H/s
[2017-12-11 12:48:46] CPU #8: 285 H, 18.81 H/s
[2017-12-11 12:48:46] CPU #4: 462 H, 30.52 H/s
[2017-12-11 12:48:46] CPU #5: 457 H, 30.20 H/s
[2017-12-11 12:48:46] CPU #3: 296 H, 19.57 H/s
[2017-12-11 12:48:46] CPU #0: 301 H, 19.84 H/s
[2017-12-11 12:48:46] CPU #1: 297 H, 19.63 H/s
[2017-12-11 12:48:46] CPU #7: 286 H, 18.89 H/s
[2017-12-11 12:48:46] CPU #6: 246 H, 16.22 H/s

When I do a control-c to kill it, watchdog never attempts to restart it. I also never get email notifications that it quit.

So for now, I'm just running that launch command from the ssh window and things are running smoothly again like on 19-1.4

EDIT: That launch command is showing -u crazydate.115 -p x where it should be -u crazydane.miner06 -p solar I would think.

mph ignores the password, but is should be passing along the MINER_PWD set in 1bash should it not?

In my case, that would be:

Code:

# For zpool use MINER_PWD="$WORKERNAME,c=btc"
MINER_PWD="solar" # Set the miner password. Default: x

It just so happens that the ip address I have mapped to miner06 is 10.0.1.115. So it looks like instead of the host name, it is passing the last part of the ip address.

EDIT2: I switched to LOCAL and that allows both miners to run.

I get this:

Code:

m1@miner06:~$ ps -ef |grep miner
avahi 905 1 0 13:09 ? 00:00:00 avahi-daemon: running [miner06.local]
m1 2067 2050 99 13:09 pts/20 00:08:16 /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10
m1 2295 1241 0 13:09 ? 00:00:00 SCREEN -dmSL miner /home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21
m1 2296 2295 0 13:09 pts/24 00:00:00 /home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21
m1 2306 1953 0 13:09 pts/17 00:00:00 screen -r miner

From the above, we have:

-u crazydane.115 -p x
-u crazydane.115 -p solar

And it should be:

-u crazydane.miner06 -p solar
-u crazydane.miner06 -p solar

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: crazydane on December 11, 2017, 11:39:05 AM

Quote from: papampi on December 11, 2017, 11:06:02 AM

Either open 3main and edit the 2 lines and add :$XMR_PORT in this section :

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]

Code:

guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
else
screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

Or run the update script again to fix it for you

I edited those 2 lines in 3main and changed 1bash back to the new way with port on a separate line. The XMR miner now connects to the pool. However, the miner still exits within 20 seconds of starting for some reason. The screen window closes immediately when this happens.

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

Topic: [ mining os ] nvoc - page 112. (Read 418557 times)