我想知道你能否帮忙
我正在运行以下版本:
OS: SMP Debian 3.2.81-1 x86_64 uWSGI: uWSGI 2.0.11.2
我手动安装了uWSGI,因为我想使用特定的版本。 使用以下命令: –
apt-get install build-essential psmisc python-dev libxml2 libxml2-dev python-setuptools cd /opt/ wget http://projects.unbit.it/downloads/uwsgi-2.0.11.2.tar.gz tar -zxvf uwsgi-2.0.11.2.tar.gz mv uwsgi-2.0.11.2/ uwsgi/ cd uwsgi/ python setup.py install
我试图在另一台服务器上复制项目已经在实际环境中工作的设置(我基本上设置了一个testing服务器环境)。
原始服务器启动时运行uWSGI。 为了弄清楚这是怎么发生的,我用了
htops
我已经能够通过一组命令行开关来识别uWSGI是否在现有的服务器上运行。 我已经设法追踪了在init.d文件夹中用这些开关初始化uWSGI的脚本。
我将这个脚本复制到我的testing服务器,并使用它运行
service script.sh start
经过各种疑难解答,主要涉及对套接字文件夹等的权限,现在当我运行这个脚本启动,如果我运行htop我可以看到uWSGI正在运行,它有我需要的完全相同的命令开关。
我想简单地把脚本放在init.d中并给它执行权限
chmod +x script.sh
只要服务器启动就足够了,但这似乎不是这种情况。 因为当我问题
reboot
在terminal,terminal重新启动,但当我进入htops,并检查uWSGI进程没有运行。
不过,如果直接重新启动后,我发出以下命令
service script.sh start
服务开始很好,我可以再次看到它在htops。
在线研究引导我提出build议,我应该尝试将脚本设置为使用chkconfig自动运行。 我使用chkconfig来安装
apt-get chkconfig
然后运行以下命令
chkconfig --list
我注意到,所有运行级别设置为closures的脚本,我试图得到启动时执行。
我运行了下面的命令
chkconfig /etc/init.d/script.sh on
现在,当我使用chkconfig检查脚本运行时开关时,它向我显示了脚本的以下输出:
script.sh 0:off 1:off 2:on 3:on 4:on 5:on 6:off
但是,当我重新启动uWSGI进程仍然没有启动。
但是,如果我只是打字
service script.sh start
在terminal服务运行正常,uWSGI运行良好。
如何在服务器重新启动时将脚本设置为运行?
编辑:
对正在正常工作的活动服务器的进一步研究已经确定,它似乎没有使用systemd来启动uWSGI。 我login到现场服务器,而有一个
/etc/systemd
文件夹,它只有一个文件夹在它的system
,没有文件。 系统文件夹中包含以下文件:
multi-user.target.wants sockets.target.wants syslog.service
所以这里没有任何与uWSGI相关的东西。
还有什么让我觉得这可能是与事情有关
/etc/init.d
文件夹,是当我运行htop并检查正在运行的服务(或守护进程)不太确定在Linux中正确的术语。 uWSGI在这里显示为运行命令行开关的签名,我在/etc/init.d
中find的脚本具有这个确切的uWSGI命令和相同的开关签名,所以我相当确信这是启动uWSGI守护进程的系统,我只是无法弄清楚我需要做什么,除了将相同的文件复制到新服务器上的/etc/init.d
并赋予它执行权限之外。
在线服务器的操作系统是:
SMP Debian 3.2.73-2+deb7u1 x86_64
和我在新的服务器上运行的操作系统是
SMP Debian 3.2.81-1 x86_64
所以他们看起来很相似? 虽然我不确定版本号中最小有效位数的8个增量有多重要。
在新服务器上没有/etc/systemd
文件夹,而在活动服务器上有一个/etc/systemd
,如上所述。 所以它似乎已经单独安装到主要的操作系统安装(因为我有一个更高版本的Debian,它没有安装在我的系统默认情况下) – 所以也许有一些相关的systemd,导致脚本开始在现场服务器,但我不太确定。
在最近的Debian(Jessie)中, initv
脚本不像他们那样工作。 考虑到你的内核版本,你不会运行使用initv
脚本的Debian。 当前Debian在/etc/rc.d
中使用systemd
和脚本是由systemd
的兼容性功能运行的( service
命令现在是一个systemd
命令,它尝试像旧的initv
命令一样)。
你有两个选择:
添加一行从/etc/rc.local
调用脚本:
/etc/rc.d/script.sh
这是一个相当脏的修复,因为它取决于systemd
另一个兼容性功能。 而且,脚本的位置已经不重要了。
为uwsgi
写一个完整的systemd
服务(这就是我所做的,以及uwsgi
文档推荐的)。 您需要创建一个名为/etc/systemd/system/uwsgi.service
,内容类似于:
[Unit] Description=uwsgi emperor After=rsyslog.service [Service] PIDFile=/run/uwsgi-emperor.pid ExecStart=/bin/uwsgi --ini /etc/uwsgi/emperor.ini ExecReload=/bin/uwsgi --reload /run/uwsgi-emperor.pid ExecStop=/bin/uwsgi --stop /run/uwsgi-emperor.pid Restart=always KillSignal=SIGQUIT Type=notify StandardError=syslog NotifyAccess=all [Install] WantedBy=multi-user.target
我使用的是皇帝模式(这也是uwsgi
推荐用于systemd
的模式),尽管它可以破解它运行一个单独的进程uwsgi
(参见下面的进一步阅读)。
您还需要启用multi-user.target
所使用的服务,它将在启动时运行。 您需要以root身份执行此操作:
systemctl enable uwsgi.service
并且uwsgi
将会从下一次启动开始(它不会马上启动,为了启动它,你需要systemctl start uwsgi.service
)。
进一步阅读:
systemd
的Arch linux维基是非常彻底的 systemd
上的Debian wiki很好,但在某些地方已经过时了(特别是,它告诉你,你需要安装它,而Jessie则不是这样) 你正在混合一些东西: chkconfig
是RedHat系列操作系统的一个脚本。 在过去,为Debian工作并不容易,现在我不相信这么做。
Weezy仍然使用initv
rc.d文件夹,对于每个runlevel一个rc.d文件夹:
/etc/rc.d/rc0.d/ /etc/rc.d/rc1.d/ /etc/rc.d/rc2.d/ /etc/rc.d/rc3.d/ /etc/rc.d/rc4.d/ /etc/rc.d/rc5.d/ /etc/rc.d/rc6.d/
你可以用(适当命名的) runlevel
命令检查你所在的runlevel
。 然后,您需要检查是否有正确的/etc/rc.d/rc*.d
文件夹中的脚本的软链接。 如果没有到脚本的软链接,则需要使用以下几行添加它:
ln -s /etc/rc.d/init.d/script.dh /etc/rc.d/rc$(runlevel | cut -d ' ' -f 2).d/script.sh
这几乎都是关于initv
脚本如何工作的。 如果在机器启动时进入运行级别2(我相信这是Debian的默认设置), init
执行的操作仅仅是为/etc/rc.d/rc2.d
每个文件service <script> start
。