Why This Shell Won't Work If It's Called from Rc.Local But Ssh

Why this shell won't work if it's called from rc.local but SSH?

Looks like starting services from rc.local is not the best practice http://bencane.com/2011/12/30/when-its-ok-and-not-ok-to-use-rc-local/. You would be better writing an init script :
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/sysinit.html

rc.local and python script

try to redirect stderr and stdout into the /startuplogfile like this :

/usr/local/bin/python3.2 "/root/Advantage/main.py" >> /startuplogfile 2>&1

you will see if an error occurs

script working manually but not via crontab?

Try adding the following which will add the error to the log file as well:

* * * * * /data/backups/scripts/server_log_check.sh > /data/backups/logs/cron_logs/server_log_check.sh_cron.log 2>&1

Also change this:

/usr/local/etc/rc.d/tomcat55 start  

to:

cd /home/root

nohup /usr/local/etc/rc.d/tomcat55 start &

This should create a nohup.out in /home/root.

SSH from shellscript without password

In most Linux distributions, an instance of ssh-agent is started when you log in. This is a background process that holds onto decrypted copies of your SSH keys; the ssh command will attempt to go through ssh-agent to gain access to the keys in order to do public-key authentication. The point of ssh-agent is that you should only need to enter your password for an SSH key once during a login session. (On some distros you don't even need to enter this - your keys are automatically decrypted when you log in.)

I'm guessing you're trying to run your script from cron, or from some other server process (like a web server or CGI script)? If so, it won't have the necessary environment variables set up for the ssh command to talk to ssh-agent - so it will prompt for a password (and thus fail if it's not being run within a terminal).

You can get around this by storing an unencrypted copy of your SSH key (so you won't need ssh-agent to decrypt it), but as this is a major security no-no this is generally only done for SSH keys that allow access to locked-down, minimally-privileged accounts.

Automatic launch a script at boot using rc.local with multiple screens that starts a sh file

Assumed your script with the commands to start the server is located in /usr/local/sbin/startup and you want to name the screen startup-server I would use:

/usr/bin/screen -dmS startup-server /usr/local/sbin/startup

This in /etc/rc.local will start your server as root!

[root@vm1]$ screen --help
    ...
    -d (-r)       Detach the elsewhere running screen (and reattach here)
    -m            ignore $STY variable, do create a new screen session.
    -S sockname   Name this session <pid>.sockname instead of <pid>.<tty>.<host>.
    ...

Example (including starting the script - NOT the screen - as different user:

# file: /etc/rc.local
/usr/bin/screen -dmS startup-server1 /usr/local/sbin/startup
/usr/bin/screen -dmS startup-server2 sudo -u git -H /usr/local/sbin/startup
/usr/bin/screen -dmS startup-server3 sudo -u postfix -H /usr/local/sbin/startup

reboot...

[root@vm1]$ screen -ls 
There are screens on:
    3292.startup-server3    (07/24/14 01:25:01) (Detached)
    3290.startup-server2    (07/24/14 01:25:01) (Detached)
    3287.startup-server1    (07/24/14 01:25:01) (Detached)
3 Sockets in /var/run/screen/S-root.

You can attach a screen with e.g.

[root@vm1]$ screen -r startup-server1

For the sake of completeness, my demo script does this:

[root@vm1]$ cat /usr/local/sbin/startup
#!/bin/bash

while [ 1 = 1 ]; do
  sleep 5
  echo "five seconds later..."
done

EDIT:

Maybe I didn't get the question right.

If your script is not working remember also:

1. The script has to be executable: chmod +x [path to script]

2. find out where the java binary is located with which java on the command line and alter your script (if which java returned e.g. /usr/bin/java):

   /usr/bin/java -Xms1024m -Xmx2048m -jar FTBServer-1.6.4-965.jar nogui

How to execute a series of commands after logging in to a remote server over SSH?

I might be missing something but in order to achieve the stated goal:

1. Log in as user1
2. Set working directory to the home of user2
3. Source .bashrc from user2

it is enough to say

ssh user1@server -t "cd /home/user2; bash --rcfile /home/user2/.bashrc -i"

Note that in most cases this would work without the -i and without giving the full path to .bashrc:

ssh user1@server -t "cd /home/user2; bash --rcfile .bashrc "

---

Related Topics