I want to start Seafile (cloud-server which needs MySQL) at the boot of my Raspberry Pi. My Problem is, that the Seafile starts befor mysql and caused many errors, because seafile needs mysql.
I took the recommended script:
#! /bin/sh
# /etc/init.d/seafile
### BEGIN INIT INFO
# Provides: seafile
# Required-Start: $local_fs $remote_fs $network mysql
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Script to start/stop/restart seafile
# Description: Simple script to start, stop or restart seafile for the cloud
### END INIT INFO
# Change the value of "user" to your linux user name
user=chromo
# Change the value of "script_path" to your path of seafile installation
seafile_dir=/home/chromo/cloud
script_path=${seafile_dir}/seafile-server-latest
seafile_init_log=${seafile_dir}/logs/seafile.init.log
seahub_init_log=${seafile_dir}/logs/seahub.init.log
# Change the value of fastcgi to true if fastcgi is to be used
fastcgi=true
# Set the port of fastcgi, default is 8000. Change it if you need different.
fastcgi_port=8000
case "$1" in
start)
sudo -u ${user} ${script_path}/seafile.sh start >> ${seafile_init_log}
if [ $fastcgi = true ];
then
sudo -u ${user} ${script_path}/seahub.sh start-fastcgi ${fastcgi_port} >> ${seahub_init_log}
else
sudo -u ${user} ${script_path}/seahub.sh start >> ${seahub_init_log}
fi
;;
restart)
sudo -u ${user} ${script_path}/seafile.sh restart >> ${seafile_init_log}
if [ $fastcgi = true ];
then
sudo -u ${user} ${script_path}/seahub.sh restart-fastcgi ${fastcgi_port} >> ${seahub_init_log}
else
sudo -u ${user} ${script_path}/seahub.sh restart >> ${seahub_init_log}
fi
;;
stop)
sudo -u ${user} ${script_path}/seafile.sh $1 >> ${seafile_init_log}
sudo -u ${user} ${script_path}/seahub.sh $1 >> ${seahub_init_log}
;;
*)
echo "Usage: /etc/init.d/seafile {start|stop|restart}"
exit 1
;;
esac
Can someone help me?
The best thing would be to set priority for starting these services in /etc/rc[runlevel].d file.
In your case, the first thing to check would be the runlevel to which you have boot into. You can check this using the command "runlevel". You can also check
Say, you have been booted in to runlevel 3. You can rename the current seafile file in directory "/etc/rc3.d".
For eg:
If the two files are
/etc/rc3.d/20seafile
/etc/rc3.d/50mysql
Rename the file as 70seafile or anything higher than 50.
This should fix the issue you are facing now.
Another workaround will be removing the seafile link to /etc/init.d directory and put a line saying
/etc/init.d/seafile start
inside the file /etc/rc.local
Please check this and let me know if it has fixed the issue for you.
Related
I setup my nodejs server successfully and I'm using it on Ubuntu 15.04 server, my issue is that I want my node applications to keep running when the server reboots so I tried pm2, forever and crontab but none of them worked for me, after rebooting I need to start the node application manually.
I tried pm2 as follow:
pm2 startup ubuntu
pm2 start appname
pm2 save
The pm2-init.sh file:
#!/bin/bash
# chkconfig: 2345 98 02
#
# description: PM2 next gen process manager for Node.js
# processname: pm2
#
### BEGIN INIT INFO
# Provides: pm2
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: $network
# Should-Stop: $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: PM2 init script
# Description: PM2 is the next gen process manager for Node.js
### END INIT INFO
NAME=pm2
PM2=/home/bashar/.nvm/versions/node/v4.1.1/lib/node_modules/pm2/bin/pm2
USER=bashar
export PATH=/home/bashar/.nvm/versions/node/v4.1.1/bin:$PATH
export PM2_HOME="/home/bashar/.pm2"
get_user_shell() {
local shell=$(getent passwd ${1:-`whoami`} | cut -d: -f7 | sed -e 's/[[:space:]]*$//')
if [[ $shell == *"/sbin/nologin" ]] || [[ $shell == "/bin/false" ]] || [[ -z "$shell" ]];
then
shell="/bin/bash"
fi
echo "$shell"
}
super() {
local shell=$(get_user_shell $USER)
su - $USER -s $shell -c "PATH=$PATH; PM2_HOME=$PM2_HOME $*"
}
start() {
echo "Starting $NAME"
export PM2_HOME
super $PM2 resurrect
}
stop() {
super $PM2 dump
super $PM2 delete all
super $PM2 kill
}
restart() {
echo "Restarting $NAME"
stop
start
}
reload() {
echo "Reloading $NAME"
super $PM2 reload all
}
status() {
echo "Status for $NAME:"
super $PM2 list
RETVAL=$?
}
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status
;;
restart)
restart
;;
reload)
reload
;;
force-reload)
reload
;;
*)
echo "Usage: {start|stop|status|restart|reload|force-reload}"
exit 1
;;
esac
exit $RETVAL
That didn't work, so I tried to use crontab as follow:
First, I create a script and named it starter.sh
#!/bin/bash
pm2 start /home/bashar/www/node/server.js
Then opened crontab editor:
crontab -e
#reboot /home/bashar/www/node/server.js
Also the above method didn't start my application on the server reboot.
Please advice,
pm2 seems to have a bug during the reboot. After adding pm2 to the automagically starting processes in /etc/init.d, the script works fine under normal processing, but does something weird under a reboot: it wipes the pm2.dump file empty. There are several bug reports like this one, but so far it's still a bug...
The easiest work-around that I've found is as follows:
Edit /etc/init.d/pm2-init.sh, and comment out the line "super $PM2 dump" in the section for stop()
Whenever you modify your pm2 process list, remember to do a manual "pm2 dump"
If anyone has a more permanent solution, please let me know... :)
For anyone who is here looking for Windows machines(as I did), pm2 startup works with unix system only.
https://pm2.keymetrics.io/docs/usage/startup/#init-systems-supported
Try this: https://www.npmjs.com/package/pm2-windows-startup
In order to install LibreOffice 4.4 into my Debian 8 (Jessie), I just got all my bash scripts from my Debian 7.5 and run them into the same way into the D8 one.
I know there was several changes into the new version but I'm not able to use my service like this anymore :
sudo service libreoffice start
When doing this doesn't start anything and I have to start it using :
sudo /etc/init.d/libreoffice start
And strange thing, when doing (bad parameter) :
sudo service libreoffice dzedjiodjzedj
...the script is perfectly executed and it displays my catched error
Here is my /etc/init.d/libreoffice file :
#
# libreoffice This shell script takes care of starting and stopping the LibreOffice Daemon
#
# chkconfig: - 80 20
#
### BEGIN INIT INFO
# Provides: libreofficedaemon
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Init.d script to run a LibreOffice Daemon
# Short-Description: start and stop LibreOffice Daemon
### END INIT INFO
NAME="LibreOffice Service"
LIBREOFFICE_HOME=/opt/libreoffice4.4
LIBREOFFICE_USER=libreoffice
export LIBREOFFICE_HOME LIBREOFFICE_USER
start() {
echo -ne "Starting $NAME. \n"
su $LIBREOFFICE_USER -c "$LIBREOFFICE_HOME/start.sh"
}
stop() {
echo -ne "Stopping $NAME. \n"
su $LIBREOFFICE_USER -c "$LIBREOFFICE_HOME/stop.sh"
}
kill() {
echo -ne "Force close of $NAME. "
killall -u $LIBREOFFICE_USER
}
cd $LIBREOFFICE_HOME
case "$1" in
start|stop)
$1;;
restart) stop; start;;
kill) kill;;
*)
echo "Usage: /etc/init.d/libreoffice {start|stop|restart|kill}"
exit 1
;;
esac
exit 0
And I just run that issue with tomcat8 service yesterday, I just started manually the service and sudo service tomcat8 start worked after that but nothing for libreoffice one..
From the Debian Jessie Release Notes :
When you are asked if any file in the /etc/init.d directory, or the /etc/manpath.config file should be replaced by the package maintainer's version, it's usually necessary to answer “yes” to ensure system consistency
With systemd you now have to use systemctl:
sudo systemctl start libreoffice
Here's some more info
I'm working on a Raspberry Pi running Raspbian running a Node.js app and trying to get it to start when the Pi boots. I found a couple of examples but I can't seem to get it working. My current code is:
#! /bin/sh
# /etc/init.d/MyApp
### BEGIN INIT INFO
# Provides: MyApp.js
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts MyApp.js
# Description: Start / stop MyApp.js at boot / shutdown.
### END INIT INFO
# If you want a command to always run, put it here
# Carry out specific functions when asked to by the system
case "$1" in
start)
echo "Starting MyApp.js"
# run application you want to start
node /home/pi/app/MyApp/MyApp.js
;;
stop)
echo "Stopping MyApp.js"
# kill application you want to stop
killall MyApp.js
;;
*)
echo "Usage: /etc/init.d/MyApp {start|stop}"
exit 1
;;
esac
exit 0
I have this in the etc/init.d folder, ran chmod +x /etc/init.d/MyApp, I'm able to run it manually, then I run sudo update-rc.d MyApp defaults, reboot and the script never runs. I've looked at some different examples, made adjustments and still no luck.
I solved this problem by first checking where node.js was installed on RaspberryPi:
which node
This gave me :
/usr/local/bin/node
Open crontab config:
sudo crontab -e
Then in my crontab :
#reboot sudo /usr/local/bin/node <complete path to your .js app> &
Save, reboot, and problem solved !
Mohit is right, but just for clarification, you can use readlink to find the full path for your Node.js app as it will be needed later to add as a cron job.
readlink -f <<name of file >>
For instance readlink -f HAP-NodeJS/Core.js results in /home/pi/HAP-NodeJS/Core.js
You can also use which node to find the full path where node.js is installed
Next, create a new cron job using sudo crontab -e and add the following code at the very end:
#reboot sudo /usr/local/bin/node <<.js application path>> &
for instance, my code looks like this.
#reboot sudo /usr/local/bin/node /home/pi/HAP-NodeJS/Core.js &
Upon reboot (or start up) , your Node.js should run. Hope this clears things.
If you're using a prebuilt Pi release like 0.10.24, you may be experiencing a PATH issue.
You can either provide the full path to the node binary as part of the start command or make sure the PATH to the node binaries are set before /etc/init.d/MyApp is ran. I had the same issue and tried both with success. Also, the stop command as you have it may not be working.
#! /bin/sh
# /etc/init.d/test
### BEGIN INIT INFO
# Provides: test
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Example initscript
# Description: This file should be used to construct scripts to be
# placed in /etc/init.d.
### END INIT INFO
# Carry out specific functions when asked to by the system
case "$1" in
start)
echo "Starting test.js"
# run application you want to start
#node /home/pi/test.js > /home/pi/test.log
/home/pi/downloads/node-v0.10.24-linux-arm-pi/bin/node /home/pi/test.js >> /home/pi/test.log
;;
stop)
echo "Stopping test.js"
# kill application you want to stop
killall -9 node
# Not a great approach for running
# multiple node instances
;;
*)
echo "Usage: /etc/init.d/test {start|stop}"
exit 1
;;
esac
exit 0
If you'd like to do sudo node, you can add the PATH to Defaults secure_path using sudo visudo.
Also, I would recommend using something like forever to keep your process running after crashes and what not.
I'm following the directions on installing Redis on a production machine (CentOS using chkconfig).
The example script I was given requires the argument start to actually start it, which it seems init.d does not do (pass arguments).
The real command that must be run is /etc/init.d/redis_6379 start, but what its actually calling is /etc/inti.d/redis_6379, which simply says use start or stop as an argument
Therefor, when my server reboots it doesnt actually start redis. What should I do here?
Here is the initial config
#!/bin/sh
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.
#
# chkconfig: - 85 15
# description: Redis is a persistent key-value database
# processname: redis_6379
REDISPORT=6379
EXEC=/usr/local/bin/redis-server
CLIEXEC=/usr/local/bin/redis-cli
PIDFILE=/var/run/redis_${REDISPORT}.pid
CONF="/etc/redis/${REDISPORT}.conf"
case "$1" in
start)
if [ -f $PIDFILE ]
then
echo "$PIDFILE exists, process is already running or crashed"
else
echo "Starting Redis server..."
$EXEC $CONF
fi
;;
stop)
if [ ! -f $PIDFILE ]
then
echo "$PIDFILE does not exist, process is not running"
else
PID=$(cat $PIDFILE)
echo "Stopping ..."
$CLIEXEC -p $REDISPORT shutdown
while [ -x /proc/${PID} ]
do
echo "Waiting for Redis to shutdown ..."
sleep 1
done
echo "Redis stopped"
fi
;;
*)
echo "Please use start or stop as first argument"
;;
esac
Make sure your script is added for service management by chkconfig. Use chkconfig --list to see the list and use chkconfig --add scriptname if it's not there. After that configure the runlevels you want it to be called into. I would guess it's 3, 4 and 5 so: chkconfig --level 345 scriptname on.
You should tell us how exactly you are running the script from init.d
But here is a dirty workaround:
Change the line
start)
to
start|'')
This will make it start if there are no parameters passed.
If you want to start a service through command line you can just add in /etc/rc.d/rc.local too for the same instead of creating a service file in init.d.
Centos redis has an init script with a chkconfig header line stating that it will start in all runlevels, which is very bad. chkconfig is used to manage the symlinks in /etc/rc.d
# chkconfig: - 85 15
I suggest that redis is a service to run in level 3 after critical services have launched (sshd for instance). In your test scenario's reboot your server before going to production. If redis cannot launch (just happened here) you cannot boot it in another runlevel to fix it.
If you implement the proper headers you can use init and also systemd (Fedora)
Your should add code below to the script /etc/inti.d/redis_6379. The status argument is used by command service --status-all.
# processname: redis_6379
# Source function library.
. /etc/init.d/functions
...
case "$1" in
status)
status -p $PIDFILE redis
script_result=$?
;;
Init.d's days are numbered, wtf are you still reading this for? There's no more sudo service, all the new kids are slapping down syscrtl
Nowadays like of course on my ubuntu 17.04 server at work, /etc/rc.local didn't even exist
Just write a new one!
rc.local is awesome, especially combined with the unix style daemonize program... those two alone, I can pretty much call it a day.
However, if you want to take rc.local to the next level, I'll cover basic ideas behind my own personal redis init.d script--same one we use on production servers across my company:
pre-empt redis complaint about system socket/file limits
slap in some linux perf and mess around with sysconf in persistent fashion
autopilot redis while i go take a nap
#!/bin/sh
### BEGIN INIT INFO
# Provides: redis
# Required-Start: $syslog
# Required-Stop: $syslog
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: start and stop redis
# Description: persistent key-value db
### END INIT INFO
NAME=redis
PATH=/opt/bin:/opt/sbin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
EXEC=/opt/sbin/redis-server
CLIEXEC=/opt/sbin/redis-cli
CONF=/etc/$NAME/$NAME.conf
PIDFILE=/var/run/$NAME.pid
SOCKET=/var/run/$NAME.sock
PERF=/tmp/redis.sysctl
KERNELPG=/sys/kernel/mm/transparent_hugepage/enabled
[ -x /opt/sbin/redis-server ] || exit 0
set -e
# tune system for better redis performance
if [ ! -f $PERF ]; then
echo "tunning redis..." &>> $PERF
echo never > $KERNELPG && cat $KERNELPG &>> $PERF
sysctl -w net.core.somaxconn=65535 &>> $PERF
sysctl -w vm.overcommit_memory=1 &>> $PERF
echo "tuned." &>> $PERF && cat $PERF
fi
next, if we're doin' it right:
let's have nice idiomatic case $money numbers, focused on starting and stopping without sorting through excessive PID tracking shenanigans
take advantage of the start-stop-daemon (i.e. can't get cut short by parent process death if there is no parent process)
case $1 in
start)
if [ ! -f $PIDFILE ]; then
echo -n "Starting $NAME: "
start-stop-daemon --start --pidfile $PIDFILE --exec $EXEC -- $CONF
echo "waiting for redis db to start..."
while [ ! -f $PIDFILE ]; do
sleep 0.1;
done
fi
PID=$(cat $PIDFILE)
echo "running with pid: $PID"
;;
stop)
if [ ! -f $PIDFILE ]; then
echo "redis is already stopped"
else
PID=$(cat $PIDFILE)
echo -n "Stopping $NAME: "
$CLIEXEC -s $SOCKET shutdown
echo "waiting for shutdown..."
while [ -x /proc/${PID} ]; do
sleep 0.1
done
echo "db stopped."
fi
;;
status)
if [ -f $PIDFILE ]; then
PID=$(cat $PIDFILE)
echo "running with pid: $PID"
else
echo "stopped."
fi
;;
restart|force-reload)
$0 stop && $0 start
;;
*)
echo "Argument \"$1\" not implemented."
exit 2
;;
esac
exit 0
edit redis.conf to designate daemonize yes. Make redis the primary responsible party for administrative PID file state (in case you were wondering why we didn't have to do anything with it in the script, except read from it if it's around)
mkdir /etc/redis
echo 'daemonize yes' >> /etc/redis/redis.conf
echo 'pidfile /var/run/redis.pid' >> /etc/redis/redis.conf
update your rc entry by name after copying and setting execution bits:
mkdir /etc/redis
vim /etc/redis/redis # keep it traditional, no .sh extensions here
# saving buffers from root all damn day...
chmod a+x /etc/init.d/redis
update-rc.d redis defaults
Here's the full example link w/ service installer. Again, be sure to edit conf and install to suit you. Most people would probably want to remove the listening file path in favor of TCP stack w/ redis port number open for client(s),
I'm currently facing an strange issue.
I'm using debian squeeze under linux voyage on an alix.2d2 and I'm tring to launch an home made script at boot using init.d.
So to do that, I'm writing a simple script, putting it into /etc/init.d/ (/etc/init.d/linknx) and using update-rc.d configuring the boot.
update-rc.d linknx start 191 12345
Before rebooting, I'm testing the script using :
service linknx start
and it works nice.
When system reboots, script is not launched. I'm trying to change the boot config using update-rc.d
update-rc.d linknx defaults
Same issue.
So After that, I'm cleaning the boot config, and add two lines in the /etc/rc.local.
> sh -c "logger -p local0.notice [LAUNCHTEST] "rc.local invoking"
> service linknx start
The first line pass, but the second one fail.
Somebody can identify the problem ?
Thanks for your help !
regards
The script:
#!/bin/sh -e1
### BEGIN INIT INFO
# Provides: linknx
# Required-Start: $local_fs $remote_fs $network $syslog $nocatsplash
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: false
# Short-Description: Start/stop linknx daemon
# Description: Simnet linknx daemond starter.
### END INIT INFO
now=$(date +"%F %k:%M:%S")
port=3671
ip=192.168.2.10
LD_LIBRARY_PATH=/usr/local/lib
knx_config_file=/etc/linknx.xml
knx_write_file=/etc/linknx.xml
log_tag="[LINKNX]"
log_level="-p local0.notice"
case "$1" in
start)
logger $log_level -t $log_tag -s "Starting linknx and eibd ..."
ldconfig -l
eibd -d -D -S -T -i ipt:$ip:$port
linknx -d --config=$knx_config_file --write=$knx_write_file
logger $log_level -t $log_tag -s "Done\n"
;;
stop)
;;
reload|restart|force-reload)
;;
test)
logger $log_level -t $log_tag -s "[$now] - [TEST] - This is a simple test to check behavior of the program ..."
;;
*)
logger $log_level -t $log_tag -s "[$now] - [FATAL] - Unknow command, only available are start|stop|restart|reload|force-reload"
;;
esac
exit 0
You should be using
insserv linknx
And not
update-rc.d linknx defaults
As of Debian 6.0 (Squeeze), update-rc.d has been replaced with insserv (see here). Why? Because 6.0 introduced a new boot process, for which you have the headers in place (the INIT INFO section at the top of the script).