|
crazydane
|
 |
December 11, 2017, 06: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.
|
|
|
|
|
|
crazydane
|
|
December 11, 2017, 06:46:43 PM |
|
Change from : 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 : 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 to "pool_password" : "MINER_PWD ",
Made the above changes except I used "MINER_PWD" instead of "MINER_PWD " and restarted, but I'm still getting: /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10
And: /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. |
|
|
|
|
papampi
Full Member
 Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 06:55:25 PM |
|
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 : WTM_AUTO_SWITCH_COINS="ZEC;ZEN;ETH;BTG;FTC;MONA;VTC;;TZC" Set WTM_AUTO_SWITCH=YES and carry on mining ... |
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 06:59:31 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: AUTO_WORKERNAME="HOST" # HOST or MAC or CUSTOM # Use HOST IP address or network card MAC address or CUSTOM name workername
|
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 07:03:03 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: 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. |
|
|
|
|
|
crazydane
|
|
December 11, 2017, 07: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 "pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",
"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,
1bash # 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 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
|
|
|
|
|
|
joshuajones02
|
|
December 11, 2017, 07:25:08 PM
Last edit: December 11, 2017, 07:38:33 PM by joshuajones02 |
|
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: 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? |
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 07:48:07 PM
Last edit: December 11, 2017, 07:58:43 PM by papampi |
|
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: 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
|
|
December 11, 2017, 07:55:28 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: 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
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 07:59:12 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: 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 ... |
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 08:02:15 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 "pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",
"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,
1bash # 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 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? 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. |
|
|
|
|
|
crazydane
|
|
December 11, 2017, 08:14:50 PM |
|
Can you try REMOTE again with the watchdog turned off? 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: 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. |
|
|
|
|
|
leenoox
|
|
December 11, 2017, 08:19:49 PM |
|
Can you try REMOTE again with the watchdog turned off? 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: 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 |
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 08:37:17 PM |
|
Can you try REMOTE again with the watchdog turned off? 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: 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 ? 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 |
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 08:44:20 PM |
|
Can you try REMOTE again with the watchdog turned off? 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: 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: 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: running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
|
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 09:07:57 PM |
|
Can you try REMOTE again with the watchdog turned off? 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: 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 : 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
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 09:08:04 PM |
|
I should have read up just a tick. There is another $running and the kill that is killing the plusCPU miner: reup=0
# running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" != "" ]
then
# target=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
target=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
kill $target
reup=1
fi
sleep 2
echo ""
echo "LAUNCHING: MINER"
echo " "
# running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" == "" ]
then
if [ $LOCALorREMOTE == "REMOTE" ]
I commented out the originals and put in modified ones below them. |
|
|
|
|
hash3r
Newbie
Offline
Activity: 10
Merit: 0
|
|
December 11, 2017, 09:24:05 PM |
|
insert in 1bash before TEAMVIEWER="NO" # YES NO
this:
xrandr --fb 1024x768 (or whatever resolution do you need)
works for both Teamviwer and VNC
perfect! you can also just run the command from guake to change on the fly. Working great with VNC, any way we can get this implemented in the next update? |
|
|
|
|
Zotix
Newbie
Offline
Activity: 1
Merit: 0
|
|
December 11, 2017, 09:30:51 PM |
|
Hello all,
I am trying to duel mine ethereum and pascal on nanopool with the email setting. I have a few machines and the email setting works fine for solo mining Ethereum and it even works with fine for duel mining on the ethereum pool, but when I try to use the email to change payout or provide public key for the pascal pool, it does not work. I have a feeling it has to do with the way pascal uses a "." in the address line, or possible the fact that I'm mining to a Poloniex account. Is there any way that I can get the pascal pool to read the email so I can make changes to payout and public key?
Here are my 1bash settings for pascal (edited for privacy):
PASC_WORKER="Workername/myemail@mail.com"
PASC_ADDRESS="1235-12.123456abvd"
PASC_POOL="pasc-us-wast1.nanopool.org:15555"
|
|
|
|
|
|
crazydane
|
|
December 11, 2017, 09:32:36 PM |
|
I should have read up just a tick. There is another $running and the kill that is killing the plusCPU miner: reup=0
# running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" != "" ]
then
# target=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
target=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
kill $target
reup=1
fi
sleep 2
echo ""
echo "LAUNCHING: MINER"
echo " "
# running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}')
running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" == "" ]
then
if [ $LOCALorREMOTE == "REMOTE" ]
I commented out the originals and put in modified ones below them. That did the trick! I'm back to REMOTE and plusCPU starts, followed by the GPU miner and both are running happily now. |
|
|
|
|
|
