I have a java code I want to run on startup ,
but I wnat to be able to see the code running on the CMD.(like when I run the java manually)
how do I do this ?
this is what I have in the rc.local
#!/bin/sh -e
#
# 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.
# Print the IP address - this was in the default - didn't touch it..
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
# run the java file from desktop
sudo java -jar Desktop/test.jar &
exit 0
Thanks ,
From what i see, you have to option.
First you maybe need to wait a moment before the next command, witch is exit 0 and will for sure exit, execute itself. Like this you will have time to read output.
Try to add sleep 1m befor exit 0
you will find more info on this command on google if you need, but 1m in exemple is for 1 minute
Other solution is to change a bit your java programm to wait for a user intput like for exemple:
System.out.println("\n Hit Return to exit... ");
String kS = scan.nextLine();
System.exit(0);
like this the java prog. will wait till you press return.
Hope you find what's best for you.
I am running the rolling release of Kali Linux, and have started to write a script that is executed by rc.local upon booting, that will be allow the user update the hostname of the computer.
rc.local:
#!/bin/sh -e
#
# 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.
/root/hostnameBoot
exit 0
hostnameBoot Script:
#!/bin/bash
# /etc/init.d/hostnameBoot
# Solution Added
exec < /dev/tty0
echo "Enter desired hostname:"
read hostname
echo "New hostname: $hostname"
#exit 0
As you can see, currently hostnameBoot prompts the user to enter a new hostname, and then returns the hostname to the user.
Upon booting, rc.local execute the script, but does not prompt the user to enter a new hostname.
Sample Boot Output:
- misc boot info -
Enter desired hostname:
New hostname:
The Sample Boot Output shows all at once and does not allow the user to enter a new hostname. Once the lines are shown, the system then continues to the login screen. Desired behavior of the system would allow the user time to enter a new hostname, then be presented with the input previously submitted.
note: The script is not the end product, it was just a proof of concept using rc.local to trigger the script.
Boot scripts, including rc.local, are usually not executed in interactive mode (i.e. with a fully functioning terminal where the user can enter data). Their output is redirected to the console (so you can see the boot messages) but the input is most likely /dev/null (so read returns immediately with nothing to read).
You will need to either manually redirect the read to use a fixed terminal all the time (e.g. read </dev/tty0) or open a virtual console to do the user input in (e.g. openvt -s -w /root/hostnameBoot). See this answer for more details.
I need to connect to my office computer through ssh, but all the ports are blocked and there is nothing to do there. I'd like to connect with reverse SSH tunneling. For that I want to use an external server that it's always on, and I want to set up my office computer to run the ssh command right at boot (before login).
I tried by modifying /etc/rc.local. These are the permissions:
-rwxr-xr-x 1 root root 385 nov 2 17:27 /etc/rc.local
The file:
#!/bin/sh -e
#
#
# 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.
sleep 1
sshpass -p 'pass' ssh -N -R 9091:localhost:22 user#server &
exit 0
Running /etc/rc.local allows me to connect from my home computer to my office computer, so the code does what it's supposed to, but it doesn't seem to do anything while booting.
Any ideas how to make the script run during booting?
Thanks.
I like to start my Siriproxy server on my Raspberry Pi on startup. I have to type
cd siriproxy
rvmsudo siriproxy server
in the Terminal to start the Siriproxy.
Is there a way to run the command on the startup?
Thanks a lot,
David
This is the script I edited:
#!/bin/sh -e
#
# 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.
# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi
#I added this line
/home/pi/siriproxy server
exit 0
/etc/init.d/cron start
You can add commands that are run as root to the /etc/rc.local script, and they will then be run at boot-up. (http://ubuntuforums.org/showthread.php?t=1822137)
From a terminal on your raspberry pi, run:
sudo nano /etc/rc.local
Add the following before the exit 0 line:
/path/to/siriproxy server
You can get the path of siriproxy by typing
which siriproxy
or depending on how your pi has siriproxy installed, it could be the full path of whatever you cd'd to, then adding "siriproxy" to the end.
Save the file and reboot to see it work! Hope this helped.
Try
screen -S ttlp
cd /home/pi/siriproxy
then
rvm siriproxy server
I haven't tried this yet, I will install it on one of my Pi's and help you.
Regards,
IC0NIC
I have a node.js script which need to start at boot and run under the www-data user. During development I always started the script with:
su www-data -c 'node /var/www/php-jobs/manager.js
I saw exactly what happened, the manager.js works now great. Searching SO I found I had to place this in my /etc/rc.local. Also, I learned to point the output to a log file and to append the 2>&1 to "redirect stderr to stdout" and it should be a daemon so the last character is a &.
Finally, my /etc/rc.local looks like this:
#!/bin/sh -e
#
# 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.
su www-data -c 'node /var/www/php-jobs/manager.js >> /var/log/php-jobs.log 2>&1 &'
exit 0
If I run this myself (sudo /etc/rc.local): yes, it works! However, if I perform a reboot no node process is running, the /var/log/php-jobs.log does not exist and thus, the manager.js does not work. What is happening?
In this example of a rc.local script I use io redirection at the very first line of execution to my own log file:
#!/bin/sh -e
#
# 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.
exec 1>/tmp/rc.local.log 2>&1 # send stdout and stderr from rc.local to a log file
set -x # tell sh to display commands before execution
/opt/stuff/somefancy.error.script.sh
exit 0
On some linux's (Centos & RH, e.g.), /etc/rc.local is initially just a symbolic link to /etc/rc.d/rc.local. On those systems, if the symbolic link is broken, and /etc/rc.local is a separate file, then changes to /etc/rc.local won't get seen at bootup -- the boot process will run the version in /etc/rc.d. (They'll work if one runs /etc/rc.local manually, but won't be run at bootup.)
Sounds like on dimadima's system, they are separate files, but /etc/rc.d/rc.local calls /etc/rc.local
The symbolic link from /etc/rc.local to the 'real' one in /etc/rc.d can get lost if one moves rc.local to a backup directory and copies it back or creates it from scratch, not realizing the original one in /etc was just a symbolic link.
I ended up with upstart, which works fine.
In Ubuntu I noticed there are 2 files. The real one is /etc/init.d/rc.local; it seems the other /etc/rc.local is bogus?
Once I modified the correct one (/etc/init.d/rc.local) it did execute just as expected.
You might also have made it work by specifying the full path to node. Furthermore, when you want to run a shell command as a daemon you should close stdin by adding 1<&- before the &.
I had the same problem (on CentOS 7) and I fixed it by giving execute permissions to /etc/local:
chmod +x /etc/rc.local
if you are using linux on cloud, then usually you don't have chance to touch the real hardware using your hands. so you don't see the configuration interface when booting for the first time, and of course cannot configure it. As a result, the firstboot service will always be in the way to rc.local. The solution is to disable firstboot by doing:
sudo chkconfig firstboot off
if you are not sure why your rc.local does not run, you can always check from /etc/rc.d/rc file because this file will always run and call other subsystems (e.g. rc.local).
I got my script to work by editing /etc/rc.local then issuing the following 3 commands.
sudo mv /filename /etc/init.d/
sudo chmod +x /etc/init.d/filename
sudo update-rc.d filename defaults
Now the script works at boot.
I am using CentOS 7.
$ cd /etc/profile.d
$ vim yourstuffs.sh
Type the following into the yourstuffs.sh script.
type whatever you want here to execute
export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH
Save and reboot the OS.
I have used rc.local in the past. But I have learned from my experience that the most reliable way to run your script at the system boot time is is to use #reboot command in crontab. For example:
#reboot path_to_the_start_up_script.sh
This is most probably caused by a missing or incomplete PATH environment variable.
If you provide full absolute paths to your executables (su and node) it will work.
It is my understanding that if you place your script in a certain RUN Level, you should use ln -s to link the script to the level you want it to work in.
first make the script executable using
sudo chmod 755 /path/of/the/file.sh
now add the script in the rc.local
sh /path/of/the/file.sh
before exit 0
in the rc.local,
next make the rc.local to executable with
sudo chmod 755 /etc/rc.local
next to initialize the rc.local use
sudo /etc/init.d/rc.local start
this will initiate the rc.local
now reboot the system.
Done..
I found that because I was using a network-oriented command in my rc.local, sometimes it would fail. I fixed this by putting sleep 3 at the top of my script. I don't know why but it seems when the script is run the network interfaces aren't properly configured or something, and this just allows some time for the DHCP server or something. I don't fully understand but I suppose you could give it a try.
I had exactly same issue, the script was running fine locally but when I reboot/power-on it was not.
I resolved the issue by changing the file path. Basically need to give the complete path in the script. While running locally, file can be accessed but when running on reboot, local path will not be understood.
1 Do not recommend using root to run the apps such as node app.
Well you can do it but may catch more exceptions.
2 The rc.local normally runs as root user.
So if the your script should runs as another user such as www U should make sure the PATH and other environment is ok.
3 I find a easy way to run a service as a user:
sudo -u www -i /the/path/of/your/script
Please prefer the sudo manual~
-i [command]
The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a loginshell...
rc.local only runs on startup. If you reboot and want the script to execute, it needs to go into the rc.0 file starting with the K99 prefix.