Question

我想知道你是否可以提供帮助。

我正在运行以下版本：

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

我正在尝试在项目已经在实时环境中工作的另一台服务器上复制设置（我实际上是在设置测试服务器环境）。

原始服务器在启动时运行uWSGI。为了弄清楚这是怎么回事，我用了

htops

我已经能够通过一组命令行开关识别uWSGI在现有服务器上运行。我已经设法跟踪在init.d文件夹中使用这些开关初始化uWSGI的脚本。

我将此脚本复制到我的测试服务器，然后使用

运行它

service script.sh start

经过各种故障排除，主要涉及对套接字文件夹等的权限，现在当我运行此脚本时，它启动，如果我运行htop，我可以看到uWSGI正在运行，它具有我需要的完全相同的命令开关。

我想简单地将脚本放在init.d中并赋予它执行权限

chmod +x script.sh

足以让它在服务器开启时启动......但似乎并非如此。因为当我发出

reboot

在终端上，终端重新启动但是当我进入htops并检查uWSGI进程时它没有运行。

但是如果直接重启后我发出以下命令

service script.sh start

服务开始很好，我可以再次在htops中看到它。

在线研究引导我建议我应该尝试将脚本设置为使用chkconfig自动运行。我使用

安装了chkconfig

apt-get chkconfig

然后运行以下命令

chkconfig --list

我注意到我试图在启动时执行的脚本的所有运行时级别设置为off。

我运行了以下命令

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

在终端上，服务运行正常，uWSGI正常运行。

如何设置脚本在服务器重启时运行？

编辑：

对正常工作的实时服务器的进一步研究已确定它似乎没有使用systemd在启动时启动uWSGI。我登录了实时服务器，但有一个

/etc/systemd

文件夹，它只有一个文件夹system，没有文件。系统文件夹中包含以下文件：

multi-user.target.wants  sockets.target.wants  syslog.service

所以这里似乎没有任何uWSGI相关的内容。

还有什么让我觉得这可能与

有关

/etc/init.d

文件夹，就是当我运行htop并检查正在运行的服务（或守护进程）时，不太确定linux中的正确术语。 uWSGI在这里显示为运行时带有命令行开关的签名，我在/etc/init.d中找到的脚本具有这个确切的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，如上所述。所以它似乎已经单独安装到主OS安装（因为我有一个更高版本的Debian，默认情况下它没有安装在我的系统上） - 所以也许有一些与systemd相关的东西导致脚本从现场服务器开始，但我不太确定。

Answer 1

杰西

在最近的Debian（Jessie）中，initv脚本不像他们那样工作。鉴于您的内核版本，您没有运行使用initv脚本的Debian。当前的Debian使用systemd，/etc/rc.d中的脚本由systemd的兼容性功能运行（service命令现在是systemd命令，试图表现得像旧的initv命令。）

您有两种选择：

添加一行从/etc/rc.local调用脚本：
```
/etc/rc.d/script.sh
```
这是一个相当脏的修复，因为它取决于systemd的另一个兼容性功能。此外，脚本的位置无关紧要。
为systemd撰写完整的uwsgi服务（这就是我所做的，以及uwsgi documentation建议的内容）。您需要创建一个名为/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
```
我使用emperor模式（这也是uwsgi推荐用于systemd的模式），尽管可以破解它来运行单个进程uwsgi（参见进一步阅读下面）。

您还需要启用multi-user.target使用的服务，该服务将在启动时运行。您需要以root身份执行此操作：
```
systemctl enable uwsgi.service
```
uwsgi将从下一次启动开始（它不会立即启动，启动时需要systemctl start uwsgi.service）。

进一步阅读：

Weezy

你在那里稍微混合了一些东西：chkconfig是RedHat系列操作系统的脚本。过去让它对Debian起作用并不容易，我不相信现在这样做很容易。

Weezy仍然使用initv rc.d文件夹，对于每个运行级别的一个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命令检查您所在的运行级别。然后，您需要检查正确的/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对service <script> start中的每个文件只执行/etc/rc.d/rc2.d。< / p>

为什么我的脚本启动UWSGI无法在启动时运行？

1 个答案:

杰西

Weezy