关于自定义脚本rc.local里开机不启动的问题--以tomcat和perl相关的脚本为例

本文将自己遇到的一些自定义脚本加入开机启动项却不成功的问题加以说明,花费了我很长时间才得以解决,当然也多谢了自己朋友的帮忙,正是因为他们的提醒,最后才找到了解决的办法,谢谢他们!!!!

系统是centos5.5 

应用:nginx+perl+fastcgi以及tomcat

现有几个脚本需加入/etc/rc.local里让他们开机自己启动,如下:

# vi /etc/rc.local

/usr/local/nginx/sbin/start_perl_cgi.sh stop

/usr/local/nginx/sbin/start_perl_cgi.sh start

/usr/local/tomcat/bin/startup.sh

最后查找资料说tomcat不启动是因为需要相关的环境变量,而且它需要的环境变量已经在/etc/profile里进行了设置:

但是死活不开机自动启动,只是找不到需要的jdk,如下设置即可:

source /etc/profile

/usr/local/tomcat/bin/startup.sh

或者:

export JAVA_HOME=/usr/local/jdk

/usr/local/tomcat/bin/startup.sh

这样tomcat就能开机自动启动了.

最让人头疼的是:/usr/local/nginx/sbin/start_perl_cgi.sh start怎么弄都不成功,不开机启动,但是手动执行却总是能成功!

脚本内容如下,其实这个脚本很简单,相信你应该没问题的,这个脚本网上很多:

#vi /usr/local/nginx/sbin/start_perl_cgi.sh

#!/bin/bash

#set -x

if [[ $# != 1 ]];then

echo "usage $0 start|stop|restart"

exit 1

fi

dir=/usr/local/nginx

stop ()

{

if [ -e $dir/logs/perl-fcgi.pid ];then

kill -USR1 `cat $dir/logs/perl-fcgi.pid` 2>&1> /dev/null

rm -f $dir/logs/perl-fcgi.pid 2>&1> /dev/null

fi

if [ -e $dir/logs/perl-fcgi.sock ];then

rm -f $dir/logs/perl-fcgi.sock 2>&1> /dev/null

fi       ##红色部分网上的没有加if判断语句和-f选项,在这里我加了,首先对其进行判断一下,不然在没有该文件的情况下会有提示信息:

echo "stop perl-fcgi done"

}

start ()

{

rm -f $dir/now_start_perl_fcgi.sh 2>&1 >/dev/null

chown nobody.nobody $dir/logs

echo "$dir/perl-fcgi.pl -l $dir/logs/perl-fcgi.log -pid $dir/logs/perl-fcgi.pid -S $dir/logs/perl-fcgi.sock" >>$dir/now_start_perl_fcgi.sh

chown nobody.nobody $dir/now_start_perl_fcgi.sh

chmod u+x $dir/now_start_perl_fcgi.sh

sudo -u nobody $dir/now_start_perl_fcgi.sh

echo "start perl-fcgi done"

}

case $1 in

stop)

stop

;;

start)

start

;;

restart)

stop

start

;;

esac

其实看完这个脚本是没有问题的!请注意里面蓝色部分注释了的内容(#set -x 这里我没有开启调试信息)

于是上网查找资料,有的说是rc.local里面需要使用绝对路径,有的说是权限问题.但是经过排查都不是这样的问题.

比如说不能调用有变量的路径即:$dir

可以在rc.local里实验一下:

#vi /etc/rc.local

dir=/usr/local/nginx

echo "hello,this is $dir" > /home/zhangzj/ceshi

保存退出,查看: #cat /home/zhangzj/ceshi

hello,this is /usr/local/nginx   #说明这样使用没有问题

最后在一朋友的帮助下说开启调试信息即:将set -x 打开,进行如下操作:

#vi /etc/rc.local

/usr/local/nginx/sbin/start_perl_cgi.sh stop > /home/zhangzj/stop

/usr/local/nginx/sbin/start_perl_cgi.sh start >/home/zhangzj/start

保存,退出:执行source /etc/rc.local 让其生效,最好执行,查看有没有错误设置以免造成开机无法启动的内容.查看调试信息:

#cat /home/zhangzj/stop

#cat /home/zhangzj/start

看他们有什么问题,然后针对问题进行解决.但是我这样执行后我这里没有错误,于是我将机器重启,再次查看上面调试信息时,出现以下情况:

注意红色的部分: sudo: sorry, you must have a tty to run sudo

!!!!意思是执行sudo 的shell默认需要tty(终端),而这里没有.在 /etc/rc.local 中的命令，是没有控制终端的。

上网查找资料说,只需如下操作即可:

注释掉 /etc/sudoers中 ‘Defaults requiretty ’.保存退出,机器重启,问题得以解决.

关于requiretty的解释如下:

If set, sudo will only run when the user is logged in to a real tty. When this flag is set, sudo can only be run from a login session and not via other means such as cron(8) or cgi-bin scripts. This flag is off by default.

1) Defaults  requiretty，修改为 #Defaults  requiretty，表示不需要控制终端。

2) Defaults  requiretty，修改为 Defaults:nobody !requiretty，表示仅 nobody 用户不需要控制终端。

3) 如果修改为 Defaults:%nobody !requiretty，表示仅 nobody 组不需要控制终端。

Defaults后面如果有冒号，是对后面用户的默认，如果没有，则是对所有用户的默认。就像配置文件中自带的一行：

Defaults    env_reset

其实这是一个很简单的问题,但是我却花了很长时间才得以解决,就是因为当时没有想到开启调试信息,可见在一个脚本执行不成功时,开启调试信息:set -x 查看其执行过程是多么的重要,这样也便于我们查找问题的关键所在.当然当你头脑发昏时,也不妨问问你的朋友,他们的意见也许对你很重要!!!!