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-dat
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
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 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
/opt/stuff/somefancy.error.script.sh
exit 0
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).
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.
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.
Well you can do it but may catch more exceptions.
So if the your script should runs as another user such as www U should make sure the PATH and other environment is ok.
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...