Topic: Is there a tutorial for using screen to auto start cgminer? (Read 29293 times)

./cgminer   2> log.$now.$$.txt

For BTC Keeper

At the outset I dont know shit about Linux but the following works for me. It basically came from this post Topic but it took me a while to get it sorted out. Everybody who posts seems to assume that every one else reading has the same skill levels as they do and they leave little "Important" bits out. I will try not to do that so if it is all a bit basic I aplogise!

Use these two scripts, the first named "stminer.sh" the second named "cgmlaunch.sh" As you can see both these are .sh files. You need to create those .sh files with the posted text inside. And make them executable
----------------------------------------------
#!/bin/sh
screen -dmS 051 ./cgmlaunch.sh
------------------------------------------------
and
------------------------------------------------
#!/bin/sh
sleep 60
export DISPLAY=:0
xhost +
now="`date +%Y%m%d%H%M%S`"
cd /home/miner/cgminer-2.3.2
./cgminer   2>log.$now$$.10151.txt
------------------------------------------------
If you look at the second script you will see the line "cd /home/miner/cgminer-2.3.2"
That shows you the directory where both scripts need to be put ie your equivalent of /home/miner. Where miner is your "named" directory. You need to give both scripts execution rights by chmod or the easy way just use the properties box/permissions and check "allow execution". You need to change "cgminer-2.3.2" to whatever you have called your installed version of cgminer and it must be in that "/miner" directory

The first script starts Screen, names it .051 and then it starts the second script, which waits 60 seconds then starts cgminer and creates a log file called 10151.txt in your cgminer directory. If you dont want the log file delete "2>log.$now$$.10151.txt" from the last line of the second script
(Use the cgminer.config file in  /home/miner/.cgminer for your GPU parameters.)

To get the first script to run at start-up you need to use the Startup Applications in Ubuntu, go to System/Preferences/Startup Applications click Add, put in a description eg "Start CGMiner" then browse to find the first script, in my case called "stminer.sh" select it, make sure the box is ticked and exit.

If all has gone according to plan and I have not left any important little bits out. When you reboot you machine will eventually start and run your cgminer. BUT it will start in "Headless Mode"
You can ssh into the machine and use Screen to view the CGMiner data.
I am guessing but I think, if you dont want Screen to run then maybe if you were to select the second script ie "cgmlaunch.sh" instead of the first in the Startup Application then maybe it will start cgminer directly.

Hope this ease's the pain.

I am sure there are more elegant and sophisticated ways of doing the above. However this has worked flawlessly for me on two machines for more than 6 months. Both on USB boot and HDD boot and its Newbie do-able!


Edit:- corrected last line of the second script to read as per the correction in Kano's post below.

This is cut and paste of the last line of the second script from one of my running miners:-  ./cgminer 2>run.$now.$$.log10151.txt

I notice you have a capital "M" there as in Miner-launcher.sh where the script has it not capitalized. I am not sure that you named the script Miner-launcher.sh, but if you did it would not launch from rc.local unless it matches case.

I know these are old post but please do Noob a favour and explain how

I am using Xubuntu 11.04 (on HDD) and CGMiner 2.3.2

I have followed the instructions in post #14 to the letter. (I think?)

 I can start the Miner from a terminal e.g “ Miner-launcher.sh” Everything works fine. Have Screen, SSH etc etc.
However I cannot get the thing to “auto start” via the /etc/rc.local
 (done  chmod +x  /etc/rc.local)

I have in /etc/rc.local as below, I have tried commenting out “rc.local” and “exit 0“ and “-e" with chmod +x after any changes
-------------------------------------------------------------------------------------
#!/bin/bash -e
/usr/local/bin/miner-launcher.sh 60 &
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.



exit 0
-----------------------------------------------------------------------------------------

For someone who knows Linux this is probably ridiculously easy!

Thanks

Finally got this working bump 

count me in. thanks.

It may not be a bug in your code maybe just by Linux noobishness showing (for a MS SQL database architect this is way outside my comfort zone ).  It seems like /etc/rc.local isn't even executing?  Is that possible?

On edit:  Don't have time to test it but I think it was just that I forgot to chmod +x rc.local ...

I'll get to debugging it when I'm done with my work for today, it's gotta be some minor quirk as the code looks fine.
For the record, I came up with this three-file approach when JWU42 asked for advice.
I launch my miners in an even more convoluted way

I tried your method jake and I can call miner-launcher manually and it starts cgminer however despite having the above line in etc/rc.local "nothing" happens on boot.  Any ideas?

Forget apt-get, use aptitude. It has an awesomely useful parameter why to help you sort out the dependencies:

# aptitude why python
i   python-pyopencl Depends python (>= 2.5)

# aptitude why openssl
i   cups     Depends ssl-cert (>= 1.0.11)
i A ssl-cert Depends openssl (>= 0.9.8g-9)


You can also put any package (it does not have to be installed) on hold which will prevent installation, removal, or upgrade:
aptitude remove gnome-bluetooth && aptitude gnome-bluetooth= should do the job

It's in the README already ...
But 'poclbm' Eh?

It's a good thing that jake262144 is n00b friendly...

A Debian install guide would be excellent with a compile cgminer from source section with suggestions on methods to locate dependancies.
To locate dpendencies I use 'apt-cache search' and 'apt-cache show', but they're not useful for things outside the repo's like libpcap or poclbm p2pool.
A minimal install including only absolutely necessary services. For instance, when I install Ubuntu it always runs bluetooth as it boots up. Since I don't have anything bluetooth I resort to 'apt-get remove 'package' ' but some things are tied to network manager and audio so must be selective when on a usable desktop.


So far, this bash session has been great. Thanks.

Why the sad face? Do you think I didn't read the man page?
I was just faster with man screen | grep Reattach  

Reading manpage I see you are correct... 

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 )

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

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.   

Jake,

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

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:
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.

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:
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:
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:

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  

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:


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).

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.

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?
    

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

Is this still the best method?

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.

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

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

       -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.

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.

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.

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:


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


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?

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 ...

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

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.