Bump - yes i know it's old...
Is this still the best method?
Which part? There is no substituting the command like screen -dmS miner startminer.sh
What can be changed, is the manner in which the above command is invoked - on my Debian-based machines, rather than launch cgminer via /etc/rc.local
and call it a day I've set it up to start as a system service. With some scripting this allows me to do control it like any other OS daemon, e.g.
/etc/init.d/bcm0 start - invokes the time-honored [i]screen -dmS bcm-0 bcm-start.sh cgminer[/i] command[sup](1)[/sup]
/etc/init.d/bcm0 getstatus - prints whether or not cgminer is up and running, returns an exit status 1 if it isn't
/etc/init.d/bcm0 getpid - prints the PID of the active cgminer executable or returns an exit status 1 if cgminer isn't running
The service can be trivially disabled via the daemon control tool [i]update-rc.d[/i]:
update-rc.d bcm0 disable
Cgminer is only invoked via an intermediary script, /usr/local/bin/bcm-start.sh, which can launch a whole array of miners (the other ones being phoenix, diabloMiner, and ufasoft's cpuminer)
This way, whatever miner I want to launch, I don't have to mess with the /etc/init.d files.
The X.org server - a prerequisite - is being launched the same exact way.
The logging module is also tightly integrated into the system, logging some pertinent parameters of the mining rig with a 6 minute interval.
Cgminer output is being kept on-record as well so that it is easily accessible should errors crop up and need to be trouble-shot.
To ensure update flexibility and safety, I have been using the following set up:
Four concurrent versions of cgminer can coexist; they are labeled cgminer-stable, -testing, -oldstable
, and -oldtesting
and reside in their own respective directories.
Upon being installed, a new cgminer compilation is assigned the testing
status by default.
Its status can be changed, e.g. to stable
at any given time.
All cgminer calls are processed via a symlink named cgminer-current
which always links to one of the four directories.
To make sense of four cgminer executables which can in some cases have the same version number but are based on different git commits, I needed to create an automatic cgminer installer (cgminer-update.sh
) which creates the version.info file (containing the git version) in the installation directory.
A fresh copy of cgminer source will be downloaded from git, compiled and automatically installed into /opt/bcm/cgminer-testing
I find it that such a tight integration with the OS is the right approach to take in machines as purpose-built as mining rigs are.
I tried hard to fit miners and miner control into the OS as snugly as possible, to stay true to the "Debian way" - whatever is might be
If anyone's interested, I might write a guide and share some code... just give me some time to do that, a week or two(2)
as I do have a day job and other real-life commitments...
Does anyone want this?
(1) actually, the user is also being changed with su bcminer
so that cgminer doesn't run as root which would be a horribly wrong idea from the system security standpoint.
(2) ummm... how does a "4 to 6 weeks" timeframe sound to you, guys?