automating tasks at bootup

[chzlchp]

I have a Folding@Home executable that I have to remember to run each time after rebooting into Linux. What I do is go to one of the tty screens (e.g., Ctr>Alt>F6) and type in the commands to change to my F@H directory, and then run the executable. Works great (well...it works) when I remember to do so. Obviously, computers automate stuff. I want to automate running this client software. I cannot. I have tried:

1) Putting the commands in .bashrc...all heck breaks loose when they are run on bootup.

2) Creating a shell script *using the same commands that work in the tty*, and again chaos occurs.

Specifically, if I try any of the above options, the resulting executable (the Stanford Gromacs software) begins doing strange things when it starts up. For some reason, that I don't understand, calling the same executable (FAH504-Linux.exe) from a script makes Gromacs somehow start up differently than when I go to a tty screen and start it with command-line entries. e.g., it cannot find the active core (or says the core is corrupted), tries to download a new one, and hangs up at that point.

How can I get this task to automate?

[kidsleep]

Could you perhaps give your distro and definition of "all heck breaks loose"?

[je_fro]

you'll need to find out how your distro handles "init scripts" and set things up that way...

[DrChuck]

calling the same executable (FAH504-Linux.exe) from a script makes Gromacs somehow start up differently than when I go to a tty screen and start it with command-line entries. e.g., it cannot find the active core

When you start the process interactively as a regular user, your environment, including paths and home directory, have been correctly set up. That won't happen inside a script, and the program won't know where to look for all the config information.
You want to put the startup command in your /etc/rc.local (or equivalent for your distro), which is run once during bootup only. Here is how I would do it:

su - FAHuser -c "FAH504-Linux.exe"

This will execute the program from a login shell owned by FAHuser.

drChuck

[hard candy]

Q: Why to run FAH as a service?
A: Service by definition will run on background and will be started when You boot up Your machine and will be "killed" when You turn off the box. It is the most effective way to increase the productivity of the FAH client and all the rest what will come out of it.


I) After previous steps (download and manual run) add couple lines of code to the end of rc.local (/etc/rc.d/rc.local) file:
cd /folding
./FAH502-Linux.exe >/dev/null &

Note: This script will run FAH under root privileges as rc.local file will be run under root privileges (all created files/folders will be under root privileges, too). To overcome this and to run FAH as regular user (RegularUser must be set to one of user who is present on this system):
su - RegularUser -c "cd /folding; ./FAH502-Linux.exe >/dev/null &"

If You ran first-time-run as root or as some other user than RegularUser then You must change FAH folder privileges:
su -
chown -R RegularUser.RegularUserGroup /folding
Only bad thing is that there is no easy (as easy as pressing [CRTL+C]) way to stop this client anymore.
As FAH will start up several processes then there is nothing else to do than hunt down and kill these processes. To make our life a little easier FAH client will die if the running cores die (should be a rule but not always...):
cd /folding
kill -15 $(ps -C $(ls *Core_*.exe) -o pid=)Note: This is a "polite" termination (waiting FAH client and cores to finish their job) and if ps -ax should still show some cores running (newer cores may have this bug) then use a forced termination (no more waiting...):
cd /folding
kill -9 $(ps -C $(ls *Core_*.exe) -o pid=)Attention! As FAH and Core different versions tend to respond differently to "killing" of these then it may be advisable to issue the same kind of "kill routines" to FAH client itself, too:
killall -15 FAH502-Linux.exeand if it is still not dead (check it with "/sbin/pidof FAH502-Linux.exe") then:
killall -9 FAH502-Linux.exe( http://forum.folding-community.org/v...?p=65627#65627 )
Note: To get a FAH client to run on multi cpu machine, You must install as many FAH clients to separate directories as there are processors in Your machine and You may need to configure Your clients to use different Machine IDs (look to "Configuring the client").
Note: Never copy FAH files between separate clients as the usual outcome is more often bad than good.
II) Another way to run FAH Client as service is to use 'screen' utility: http://forum.folding-community.org/v...?p=13756#13756
Usage:


1) Fire up 'screen';
2) Start FAH Client:
cd /folding
./FAH502-Linux.exe

3) If You want to leave this console/session and let the FAH run press CTRL+a+CTRL+d or run 'screen -d' on this computer (from another console/session);
4) To regain the FAH session run 'screen -r' (if You have multiple screen utilities running then You must specify it).;
5) Goto 3;

From FAH Linux wiki

[chzlchp]

Q: Why to run FAH as a service?
A: Service by definition will run on background and will be started when You boot up Your machine and will be "killed" when You turn off the box. It is the most effective way to increase the productivity of the FAH client and all the rest what will come out of it.


I) After previous steps (download and manual run) add couple lines of code to the end of rc.local (/etc/rc.d/rc.local) file:
cd /folding
./FAH502-Linux.exe >/dev/null &

Thanks for the input folks. I'll try to address some general answers framed around this quote. I came here first, 'cause this was the most verbose of the responses, and gave me more specific directions to chew on and try to bomb my system with.

Firstly, I made a coupla changes to the above lines. I added a tilde "~" to the first line: cd ~/folding, then corrected the intended executable to 'FAH504', my downloaded version.

I hadda switch to root (su) to be allowed to alter the shell file 'rc.local'. So, the lines as I added them were:

cd ~/folding@home #my client directory
./FAH504-Linux.exe >/dev/null & #make it all happen!

Then...nothing happened. I rebooted, and...nadda. My startup did not balk, or do strange things, but neither did it start the F@H Gromacs thingy. To be sure, I went to 'top'-nothing going on there. Went back to the rc.local file to make sure the intended lines were in place (I put them at the very end). They were there.

Early on, one of the methods I had tried was making a bash script (#!/bin/bash...etc., etc.) and the first line I put in it, to see what would happen, was 'cd ~/some.directory'. I noticed that there were no results (yes, I did a 'u+x' to give myself executable privileges). That was one of the other questions I was going to pose..."How come a simple command that works on the command line would not work when put into a shell script". Relevant question here, because the same idea was presented (above) and also failed to work. (Out of curiosity, why are you directing the output to '/dev/null'? Isn't it supposed to be allowed to accumulate in its' required repository, so the data will be available to send back to Stanford? What am I missing here in the logic?)

Now...my 'rant'. I have made, for a number of weeks actually, a concerted effort to figure this out myself. Really, I have. I've gone into every book I own, Googled, daydreamed at work, etc., etc. I do not think that, in a hundred years, I would have ever bolted straight up from a deep sleep and said, "Aha, I should go to the /etc/blah, blah/rc.local file!". I never heard of that file. I never saw it in any of my 'readings'. I never knew it existed. Had a continued on my own, I NEVER WOULD HAVE FOUND THE RIGHT ANSWER. What am I missing here? Obviously, the right answer was not intuitively available, nore available from literature, nor from any other thing that I can think of. The advice is always, read...read...read some more. What clue is out there that I would have forever missed, that caused me to have to bother other folks for the answers, all of whom seemed to have just this right answer at their fingertips? Where does the divine inspiration come from? What sense of strategy, 'first thoughts', 'obvious places to start looking', am I missing? I had sorta used this as a test case to see if I could figure things out for myself. I failed miserably, and obviously would have continued failing. What is the answer?

[je_fro]

well, I view it as just starting another service...like postfix, or apache, or syslog, or cron...
this is accomplished through your systems init scripts. I use gentoo, so my init system is probably different than yours, but I have the script /etc/init.d/foldingathome. Unfortunately all I have these days is a sparc box, so no access to F@H. Take a look at our "Just folded my first protein" thread (it's long) but I know there are some init scripts in there that could be helpful.

[chzlchp]

Why does the the built-in command:

cd /some_directory

work when entered on the command line, but not work when entered into a shell script:

#!/bin/bash
cd /some_directory

?

[je_fro]

works for me

#!/bin/bash
cd / ;
echo `pwd` ;
cd ~/ ;
echo `pwd` ;
exit

$ ./test.sh
/
/home/je_fro

[chzlchp]

Lemme ask this question...

Where do I start?

[bwkaz]

works for me

#!/bin/bash
cd / ;
echo `pwd` ;
cd ~/ ;
echo `pwd` ;
exit

$ ./test.sh
/
/home/je_fro

Um... why did you have the echo and the backticks in there? Just run pwd; it'll print its output.

I believe chzlchp's problem is coming into play because child processes can never modify the environment (including the "current working directory") of their parent. (Well, unless the parent establishes some kind of protocol, and does the modification itself whenever the child tells it to. But nothing like that happens between shells.)

So if I have a shell script whose source is:

#!/bin/bash

cd /var/log
pwd

named "changedir.sh", and I have a script whose source is:

#!/bin/bash

cd /
pwd
changedir.sh
pwd

and I run the second script, this is the output I will get:

/
/var/log
/

Notice how after the child script runs, the current directory reverts to / -- which is the current directory of the parent. Any environment changes made by the child are lost. (And if I do a "pwd" after running the second script, it will not print /, but rather whatever directory I ran the second script from; probably my home directory.) Linux runs each shell script in a different process, each with their own "copy" of the shell interpreter.

(DOS and cmd.exe, by the way, are different -- they run all .bat and .cmd scripts in one instance of the interpreter; one command.com or cmd.exe process. So when you call into a sub-script, it runs inside the same process, and any changes made to the current working directory or to the environment variables will persist after the sub-script has finished. But only until the outermost script is finished; at that point, all changes are lost because the command.com or cmd.exe process gets torn down.)

[je_fro]

Um... why did you have the echo and the backticks in there? Just run pwd; it'll print its output.

Because that's the way I wroote it
I'm not a friggin programmer, so I wrote it in a way I was pretty sure would work the first time.

[chzlchp]

works for me

#!/bin/bash
cd / ;
echo `pwd` ;
cd ~/ ;
echo `pwd` ;
exit

$ ./test.sh
/
/home/je_fro

Can I just borrow your computer? then it would work for me, too.

(echo $BASH_VERSION = 2.05b.0(1), running on Mandrake 10.1) the same script lines as you have detailed above don't do squat on my 'puter.

[je_fro]

what do you mean didn't do squat?
did you chmod +x filename.sh ?

[chzlchp]

what do you mean didn't do squat?
did you chmod +x filename.sh ?

I guess the problem was as exhaustingly laid out by bwkaz...the whole parent/child thingy. (Oh, well...there goes my day. Now I'm gonna curl up with "A Practical Guide to Linux"-Mark G. Sobell, and read about p/c relationships all day. Not my kids-linux children).

Anyway, here's what I've gleaned; what I did; and what didn't work. I went back to the 'test-bed' script ('test.sh' -- thanks for the title) and discovered that putting a shell command, as bwkaz suggested DOES work:

#!/bin/bash
python ~/some_directory/next_directory/a_script.py

That worked-the python script I called clanked away perfectly (I deliberately put the script in a different directory to prove a coupla things at once). So, obviously, I can put this complete command:

bash ~/folding@home/FAH504-Linux.exe &

into the proper initialization file, and it will go to work when I boot in. Apparently, the file, 'etc/rc.d/rc.local' ain't the right one. When I rebooted, 'squat' happened. Again, the bootup did not give any indication that it sensed my request (in the 'rc.local' file), and 'top' agrees that F@H has not been activated.

That file (rc.local***) begins with these lines:

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

The invitation seems genuine enough. It also validates your insistence that I want to go the 'init scripts' route. Apparently what I'm chasing down here is a subset of your assertion. Correct? I guess, I'm in the right church but the wrong pew, huh? (So why wouldn't I just do the 'full Sys V style init stuff' as suggested above? Coupla reasons. I'm starting off in a simpler way-simpler damage?-and just the name 'full Sys V' scares heck outta me.)

***(I love saying that. almost like I always knew it was there)