如何缩短 inittab 进程条目,也就是将 init 看到的环境变量放在哪里?

发布于 2024-07-21 21:27:25 字数 1442 浏览 4 评论 0原文

我正在设置 Debian Etch 服务器来使用 nginx 托管 ruby​​ 和 php 应用程序。 我已成功配置 inittab 以在启动时使用 respawn 操作启动 php-cgi 进程。 在服务 1000 个请求后,php-cgi 工作进程死亡并由 init 重新生成。 inittab 记录如下所示:

50:23:respawn:/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 8000 -C 3 -u someuser -- /usr/bin/php-cgi

我最初在一个单独的脚本中编写了进程条目(第三个冒号之后的所有内容)(只是因为它很长)并将该脚本名称放入 inittab 记录中,但是因为该脚本将运行其单行死了,系统日志充满了这样的错误:

May  7 20:20:50 sb init: Id "50" respawning too fast: disabled for 5 minutes

因此,我摆脱了脚本文件,只是将整行放入 inittab 中。 此后,系统日志中不会显示任何错误。

现在我正在尝试使用 thin 来提供 Rails 应用程序服务。 我可以通过运行以下命令成功启动瘦服务器:

sudo thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

无论我是否使用 -d(守护进程)标志,它的工作原理显然都完全相同。 无论哪种方式,命令行控制都会立即返回(进程已被守护)。 如果我将整个命令(减去 sudo 和绝对路径)放入 inittab 中,init 会(在 syslog 中)抱怨进程条目太长,因此我将选项放入 /etc/profile 中的导出环境变量中。 现在我可以使用以下命令成功启动服务器:

sudo thin $THIN_OPTIONS start

但是当我使用 respawn 操作将其放入 inittab 记录中时,

51:23:respawn:/usr/local/bin/thin $THIN_OPTIONS start

日志清楚地表明该环境变量对 init 不可见; 就好像该命令只是“薄启动”。

如何缩短 inittab 进程条目?除了 /etc/profile 之外还有其他文件可以设置 THIN_OPTIONS 环境变量吗? 我之前使用 php-cgi 的经验告诉我,我不能将整个命令放在单独的脚本中。

I am setting up a Debian Etch server to host ruby and php applications with nginx. I have successfully configured inittab to start the php-cgi process on boot with the respawn action. After serving 1000 requests, the php-cgi worker processes die and are respawned by init. The inittab record looks like this:

50:23:respawn:/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 8000 -C 3 -u someuser -- /usr/bin/php-cgi

I initially wrote the process entry (everything after the 3rd colon) in a separate script (simply because it was long) and put that script name in the inittab record, but because the script would run its single line and die, the syslog was filled with errors like this:

May  7 20:20:50 sb init: Id "50" respawning too fast: disabled for 5 minutes

Thus, I got rid of the script file and just put the whole line in the inittab. Henceforth, no errors show up in the syslog.

Now I'm attempting the same with thin to serve a rails application. I can successfully start the thin server by running this command:

sudo thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

It works apparently exactly the same whether I use the -d (daemonize) flag or not. Command line control comes immediately back (the processes have been daemonized) either way. If I put that whole command (minus the sudo and with absolute paths) into inittab, init complains (in syslog) that the process entry is too long, so I put the options into an exported environment variable in /etc/profile. Now I can successfully start the server with:

sudo thin $THIN_OPTIONS start

But when I put this in an inittab record with the respawn action

51:23:respawn:/usr/local/bin/thin $THIN_OPTIONS start

the logs clearly indicate that the environment variable is not visible to init; it's as though the command were simply "thin start."

How can I shorten the inittab process entry? Is there another file than /etc/profile where I could set the THIN_OPTIONS environment variable? My earlier experience with php-cgi tells me I can't just put the whole command in a separate script.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

尘曦 2024-07-28 21:27:25

为什么你不打电话给包装商,让他们根据你的选择开始瘦身呢?

start_thin.sh:
#!/bin/bash
/usr/local/bin/thin -a 127.0.0.1 -e 生产 -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

然后:
51:23:respawn:/usr/local/bin/start_thin

And why don't you call a wrapper who start thin whith your options?

start_thin.sh:
#!/bin/bash
/usr/local/bin/thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

and then:
51:23:respawn:/usr/local/bin/start_thin

段念尘 2024-07-28 21:27:25

init.d 脚本

使用脚本

/etc/rc.d/init.d

并设置运行级别

以下是一些 thin、ruby、apache 的示例

http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin< /a>

http://blog. Fiveruns.com/2008 /9/24/rails-automation-at-slicehost

http://elwoodicious.com/2008/07/15/nginx-haproxy-thin-fastcgi-php5-load-balanced-rails-with-php-support /

其中提供了要使用的示例初始化脚本。

编辑
Asker 指出这不会允许重生。 我建议分叉 init 脚本并放弃该进程,这样 init 就不会挂起(它可能会检查脚本本身的 fork() )。 然后创建一个无限循环,等待服务器进程终止并重新启动它。

编辑2
看来 init 会分叉该脚本。 只需一个循环就可以完成。

init.d script

Use a script in

/etc/rc.d/init.d

and set the runlevel

Here are some examples with thin, ruby, apache

http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin

http://blog.fiveruns.com/2008/9/24/rails-automation-at-slicehost

http://elwoodicious.com/2008/07/15/nginx-haproxy-thin-fastcgi-php5-load-balanced-rails-with-php-support/

Which provide example initscripts to use.

edit:
Asker pointed out this will not allow respawning. I suggested forking in the init script and disowning the process so init doesn't hang (it might fork() the script itself, will check). And then creating an infinite loop that waits on the server process to die and restarts it.

edit2:
It seems init will fork the script. Just a loop should do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文