Is there a tutorial for using screen to auto start cgminer?

[DeathAndTaxes]

I am looking for tutorial to auto-start cgminer in a screen.

Current like I simply have an auto.sh script to run cgminer on boot.  I would like to have it run in screen instead but I seem to have issue getting it working.

If you have cgminer running in a screen automatically please provide a quick snippet on how you got it running.

[Lundy]

All I did was put "screen cgminer **************"    in my auto.sh file and it works so I can SSH into them.

[kano]

All I did was put "screen cgminer **************"    in my auto.sh file and it works so I can SSH into them.

Hmm - not enough.
You also at least need to export DISPLAY=:0 in front of cgminer - or better in a script that does at least this:

#!/bin/sh
export DISPLAY=:0
cd ? ? ? (this would be something like "cd ~/cgminer-2.0.8/" or "cd /home/ubuntu/cgminer-2.0.8/")
now="`date +%Y%m%d%H%M%S`"
./cgminer .... 2> run.$now.$$.log

and then to start it: "screen scriptname"
(don't forget to "chmod +x scriptname")

or if you want it to always restart if it crashes:

#!/bin/sh
export DISPLAY=:0
cd wherever (this would be something like "cd ~/cgminer-2.0.8/" or "cd /home/ubuntu/cgminer-2.0.8/")
while true ; do
 now="`date +%Y%m%d%H%M%S`"
 ./cgminer .... 2> run.$now.$$.log
 sleep 2
done

but thus has one minor danger that if it doesn't work - it will continually try every 2 seconds ...

[gnar1ta$]

I have 2 remote rigs that auto start, but I don't use auto.sh.  I added mine.sh to startup programs in the GUI which looks like this:

Code:

#!/bin/sh
screen -dmS miner ./CG

This starts a detached screen session, miner, and runs the CG script:

Code:

#!/bin/sh
export DISPLAY=:0
xhost +
now="`date +%Y%m%d%H%M%S`"
cd <cgminer dir>
./cgminer .... 2> run.$now.$$.log

The two scripts and xhost + were the only way I could get it to start and not seg fault when I connected.  What is the best way to make this work without having to use the GUI and two scripts?

[DeathAndTaxes]

Sadly I believe AMD drivers require xhost.  Stupid yes because a supercomputer wouldn't want xserver running on every node but they don't work without them.  I guess it being a dependency in early versions makes sense given the "graphical roots" but there is no reason for OpenCL to be dependent on a GUI.

[DeathAndTaxes]

I have 2 remote rigs that auto start, but I don't use auto.sh.  I added mine.sh to startup programs in the GUI which looks like this:

Code:

#!/bin/sh
screen -dmS miner ./CG

You can also add the command to:
/etc/xdg/lxsession/LXDE/autostart

What does the -dmS parameters do?  I assume d is for start disconnected?

I got autostart working but I think using some of your and Kano code I can do it better.

[gnar1ta$]

       -d -m   Start screen in "detached" mode. This creates a new session but
               doesn't  attach  to  it.  This  is  useful  for  system startup
               scripts.

       -D -m   This also starts screen in "detached" mode, but doesn't fork  a
               new process. The command exits if the session terminates.

       -S sessionname
            When creating a new session, this option can be used to specify  a
            meaningful  name for the session. This name identifies the session
            for "screen -list" and "screen -r"  actions.  It  substitutes  the
            default [tty.host] suffix.

I should change it to -D, the way I have it when I quit cgminer the screen session terminates and I get no summary screen.  It won't start detached without -m though.

[kano]

As long as:
1) You boot into a GUI
2) The script runs as the same user as the GUI (usually 'ubuntu')
You don't need xhost

[gnar1ta$]

As long as:
1) You boot into a GUI
2) The script runs as the same user as the GUI (usually 'ubuntu')
You don't need xhost

That might be where I run into issues. My rigs are headless after I set them up.

[kano]

As long as:
1) You boot into a GUI
2) The script runs as the same user as the GUI (usually 'ubuntu')
You don't need xhost

That might be where I run into issues. My rigs are headless after I set them up.

Mine is headless also (i.e. there is no cable running to a display)
However, you can still startx if it knows about the graphics cards.
The xubuntu in my cgminer setup script always boots to GUI even if there is no physical display connected.

[JWU42]

Bump - yes i know it's old...

Is this still the best method?

[jake262144]

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.

Code:

/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 stop
/etc/init.d/bcm0 restart
/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⁽²⁾ as I do have a day job and other real-life commitments...

Does anyone want this?

Notes:
(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?
    

[JWU42]

Some good stuff here.  I am not wise at all with Bash scripting -- trying to learn some simple stuff.  For now, on 2 boxes (4x7970) I do the following:

Code:

1.  screen -mdS cgm
2.  screen -r cgm
3.  cd ~/BTC/cgminer
4.  export DISPLAY=:0
5.  export GPU_USE_SYNC_OBJECTS=1 ***An issue with 7970's on 2.6 - gets rid of the CPU bug***
6.  ./cgminer

I would like to have it auto start on boot after a 60 (or longer) second delay (i.e., enough time to stop the miner if needed).

[jake262144]

I admit it's going overboard but for the sake of elegance and clearly divided code I suggest you go with three files:
/etc/rc.local for autostart,
/usr/local/bin/miner-launcher.sh as a generic launcher you will invoke if you ever need to restart your miner.
/usr/local/bin/startcgminer.sh for launching cgminer. Cgminer technicalities belong here.


/etc/rc.local should include this line, let's keep it clean:

Code:

/usr/local/bin/miner-launcher.sh 60 &

That 60 is passed as a parameter to miner-launcher. It will be used for specifying how long miner-launcher should wait before starting the miner.
The ampersand returns control to rc.local at once, without waiting for the whole minute until miner-launcher is done with its work.


/usr/local/bin/miner-launcher.sh might look something like that:

Code:

#!/bin/bash
DEFAULT_DELAY=0

if [ "x$1" = "x" -o "x$1" = "xnone" ]; then
   DELAY=$DEFAULT_DELAY
else
   DELAY=$1
fi

sleep $DELAY

screen -dmS cgm su your_user_name -c "/usr/local/bin/startcgminer.sh"     #this will run your miner as a specified user, you need to replace your_user_name with an actual username
# if you have no issue with cgminer running as root by default, comment out the above line and uncomment the one below:
#screen -dmS cgm /usr/local/bin/startcgminer.sh

The miner-launcher might be upgraded to take a username or miner-dependent script as parameters. You could then call miner-launcher.sh startcgminer.sh or miner-launcher.sh 15 startdiablominer.sh to launch your miner of choice.


/usr/local/bin/startcgminer.sh is a good place for the implementation details:

Code:

#!/bin/bash
export DISPLAY=:0
export GPU_USE_SYNC_OBJECTS=1

cd /home/your_user_name/BTC/cgminer     # avoid using relative paths in scripts, this will save you a lot of headache. You need to replace your_user_name with an actual username
./cgminer
# or perhaps ./cgminer 2> cgminer.log     #cgminer output is being logged to cgminer.log

You need to make /usr/local/bin/miner-launcher.sh and /usr/local/bin/startcgminer.sh executable:
chmod +x /usr/local/bin/*miner*.sh

Make sure the files are owned by root (it's insecure to have user-writable executable files in system directories):
chown root:root /usr/local/bin/*miner*.sh


When you kill cgminer, simply invoking miner-launcher.sh will launch a fresh instance of screen for you and execute your favorite miner inside.
Since the -m argument is passed to screen, screen will die together with cgminer.


Am I forgetting something?? Uhmmm... don't think so.
Will this work as is, without any additional tinkering or debugging? This better work or else  

[jake262144]

Oh, one other thing.
If having to constantly type screen -r cgm is bugging you, a good solution might be creating an alias in your .bashrc file.
You need to append the following line to ~/.bashrc:

Code:

alias rbcm='screen -r cgm'

Your system just learned a new command: rbcm (as in reattach bitcoin miner) will be translated to screen -r cgm.
Nifty.

Just keep in mind that when you su as root, you use root's home directory instead of your own so you need to update /root/.bashrc with that alias as well.

[JWU42]

Jake,

Thanks for this - let me get it working and will happily tip you for the efforts!

[DeathAndTaxes]

Oh, one other thing.
If having to constantly type screen -r cgm is bugging you, a good solution might be creating an alias in your .bashrc file.
You need to append the following line to ~/.bashrc:

Code:

alias rbcm='screen -r cgm'

Your system just learned a new command: rbcm (as in reattach bitcoin miner) will be translated to screen -r cgm.
Nifty.

Just keep in mind that when you su as root, you use root's home directory instead of your own so you need to update /root/.bashrc with that alias as well.

Is there a way to reattatch but if it is already attached, detach and then reattach.  Sometimes I check on rigs from multiple locations so it becomes
screen -r cgminer
"there is no session to attach"
screen -d cgminer
screen -r cgminer

I mean I am lazy that is a LOT of typing.   

[JWU42]

To re-attach to an attached session do...

Code:

screen -dR cgminer

[jake262144]

Is there a way to reattatch but if it is already attached, detach and then reattach.  Sometimes I check on rigs from multiple locations so it becomes
I mean I am lazy that is a LOT of typing.  

alias rbcm='screen -d -r cgm'

You don't want to go the '-d -R' way because -R would even create an empty screen session which won't help.
If there's no screen session that means cgminer must have died so we need to run the miner-launcher.sh

If for whatever reason the miner software gets unstable and keeps dying every now and then defining
alias nrbcm='screen -d -r cgm || miner-launcher.sh'
might be useful (n as in necro rbcm - raise from the dead if necessary )

[JWU42]

Reading manpage I see you are correct...