Quote from: dalenorman2005 on February 04, 2014, 02:17:00 PM

Quote from: ad3000 on February 04, 2014, 04:14:40 AM

Quote from: djeZo on January 31, 2014, 06:05:01 PM

Quote from: Quacko on January 31, 2014, 03:40:45 PM

Is the issue already resolved where when cgminer is restarted that the correct pool (the one of the customer) is connected to again? And also his/her backup pools?

Enable save command and will work.

FYI, for those using BAMT, the save call in the api will create a new cgminer.conf under /.cgminer/cgminer.conf .
This is of course useless since BAMT starts cgminer pointed to /etc/bamt/cgminer.conf

A workaround is to schedule a job to check for updates to /.cgminer/cgminer.conf and overwrite /etc/bamt/cgminer.conf . This will restore your customers pools in the event that you need to reboot/power outage/etc. Unfortunately the cgminer.conf created is a bit over-complicated, and duplicates values for each of your GPUs, even if the values are the same for all of them... regardless it does work, and is the best for the customer.

Login to your BAMT box using ssh and perform the following:
sudo crontab -e
Add the following to the bottom of the crontab (This will check for updates every 5 minutes and only overwrite when changes are made)

Code:

*/5 * * * * cp -u /.cgminer/cgminer.conf /etc/bamt/cgminer.conf >/dev/null 2>&1

Exit (and save)

Also, please keep in mind that SMOS linux has a script that will periodically mine for the developers, thus robbing your customers of time. Use BAMT or SMOS bee edition, or manually remove the offending code.

Hey, thanks a lot for this. it's a great help. i have 3 concerns, but bear in mind, i'm a linux idiot, so please, speak to me like i'm a child...

1. when i save the file - command-o, it says "File Name to Write: /tmp/crontab.xbPyzp/crontab". Why the odd tmp path? am i really accomplishing anything, or just editing a tmp file that won't survive a reboot?

2. before i made this change, my cgminer .cgconfig file contained my pools and the rest of my cgconfig info. of course, it also granted lease rig's server access to my api. after this change, it now has duplicate entries for each gnu, just like you said it would. but it still has my pools and not my renter's pools. if i remove my pool info from my cgconfig i can't start cgminer without it error'ing out. shouldn't i see my renter's pool info in my cgconfig file now?

3. if my rig is not rented, it mines under my pool. when someone rents it, it always goes straight to their pool. that part is very reliable. so why have to make this workaround in the first place - why not just schedule the server to force it to the renter's pool every x minutes, whether it needs it or not? wouldn't that be more elegant?

1. Yes, it does the same for me. It does in fact survive a reboot.
2. I noticed the customers pools were listed last sometimes. You may also need to change the permissions on both the /.cgminer/cgminer.conf and /etc/bamt/cgminer.conf files, although I'm not positive. I did this step previously, and am not sure what's needed from a default install... I hope to work out a BAMT guide from scratch, unfortunately things are insane at work right now, so my free time is a bit low...
3. I agree, it would be nice if LeaseRigs would simply re-issue the pool changes every 5 minutes or so, but I have no idea what kind of strain this would place on their servers. Regardless, the workaround I posted should accomplish much of the same thing.