如何将参数传递给Linux守护进程/服务

I have created a Linux daemon (in C language) to send certain information via UDP to another computer. It requires of course the remote IP address and the port number. I store this daemon in /usr/local/bin/ and I also created a script in /etc/init.d/ to start|stop|restart the daemon.

我创建了一个Linux守护进程(用C语言),通过UDP将某些信息发送到另一台计算机。它当然需要远程IP地址和端口号。我将这个守护进程存储在/ usr / local / bin /中,我还在/etc/init.d/中创建了一个脚本来启动|停止|重启守护进程。

So far, the IP address and the port number are passed to the daemon, directly by the script. By example, the start() part of the script looks like this:

到目前为止,IP地址和端口号直接由脚本传递给守护进程。例如,脚本的start()部分如下所示:

start() {
  /usr/local/bin/lvsload_udp_s 192.168.122.25 47239
}

So, when the remote IP and/or port number changes, I have to modify my script, instead of modifying some configuration file. It is a bad practice, I know.

因此,当远程IP和/或端口号发生变化时,我必须修改我的脚本,而不是修改某些配置文件。我知道,这是一种不好的做法。

What is the best way of passing the arguments to my daemon? Thanks

将参数传递给我的守护进程的最佳方法是什么?谢谢

4 个解决方案

#1

Why do you think command line parameters are bad?

为什么你认为命令行参数不好?

Configuration files are additional work, since you need to parse them. And going with your example, modifying a configuration file = modifying one file. Modifying a script = modifying one file. Doesn't seem like much of a difference, when you only have a small number of arguments. You can even stick the parameters into variables at the top of the script, which makes it almost like a config file :-) Some scripts even source such "variable setting scripts" so it really looks like a configuration file.

配置文件是额外的工作,因为您需要解析它们。继续您的示例,修改配置文件=修改一个文件。修改脚本=修改一个文件。当你只有少量参数时,似乎没什么区别。你甚至可以将参数粘贴到脚本顶部的变量中,这使得它几乎就像一个配置文件:-)有些脚本甚至会提供这样的“变量设置脚本”,所以它看起来真的像配置文件。

If you can find a reason why command line parameters are bad, then there's a good chance that you'll also have an idea what to use instead. If, on the other hand, you can't even explain why the command line parameters are bad, then there's probably nothing wrong with using them...

如果你能找到命令行参数不好的原因,那么你很可能也知道要使用什么。另一方面,如果你甚至无法解释为什么命令行参数不好,那么使用它们可能没什么问题......

#2

Q: So far, the IP address and the port number are passed to the daemon, directly ... It is a bad practice, I know.

问:到目前为止,IP地址和端口号直接传递给守护进程......我知道这是一种不好的做法。

A: Why do you think it's "bad practice"????

A:你为什么认为这是“不好的做法”????

"Good practices" include:

“良好做法”包括:

"DRY" (Don't Repeat Yourself - store data in one and only one place)

“干”(不要重复自己 - 将数据存储在一个且只有一个地方)
"KISS" (Keep it Simple, Stupid)

“吻”(保持简单,愚蠢)

I'd say one parameter (command line IP address) in one script (your init.d startup script) adheres to both principles pretty well :)

我会说一个脚本中的一个参数(命令行IP地址)(你的init.d启动脚本)很好地遵循这两个原则:)

IMHO...

PS:

If you really think a configuration file is appropriate - if there's lots of complex configuration data that needs to be parsed at startup), then two appropriate places would be:

如果你真的认为配置文件是合适的 - 如果有很多复杂的配置数据需要在启动时解析,那么两个合适的位置是:

Store the config file in /etc (and your app in /usr/local/bin)

将配置文件存储在/ etc中(并将您的应用程序存储在/ usr / local / bin中)

... or ..

... 要么 ..
Store the config file in your app's install directory (and possibly define a global environment variable to point to the install directory)

将配置文件存储在应用程序的安装目录中(并可能定义一个全局环境变量以指向安装目录)

#3

This is distro specific. On debian, for example, the convention is that /etc/init.d/foo includes a line like "source /etc/default/foo". That file contains only environment variables e.g. DAEMON_ARGS="--remote-ip=192.168.0.1".

这是特定于发行版的。例如,在debian上,约定是/etc/init.d/foo包含类似“source / etc / default / foo”的行。该文件仅包含环境变量,例如DAEMON_ARGS = “ - 远程IP = 192.168.0.1”。

If you build a debian package using debhelper it will create this structure for you automatically. I'm sure there are similar tools for creating "standard" RPMs too.

如果使用debhelper构建debian包,它将自动为您创建此结构。我确信也有类似的工具来创建“标准”RPM。

#4

Use environment variables:

使用环境变量:

// include stdlib for getenv

port = getenv("MY_DAEMON_PORT");
host = getenv("MY_DAEMON_HOST");

// convert port to integer...

As I recall this is somewhat conventional with processes launched from init.d.

我记得,从init.d启动的进程有点传统。

Since you've mentioned that you're using Ubuntu, have a look at /etc/environment - see the docs. But as someone has already mentioned this is dependent on your system/distro; another way is to keep the environment variables in e.g. /etc/myDaemon.env, then source that from your init script with:

既然你已经提到过你正在使用Ubuntu,请查看/ etc / environment - 请参阅文档。但正如有人已经提到过这取决于你的系统/发行版;另一种方法是将环境变量保持在例如/etc/myDaemon.env,然后从你的init脚本中获取:

. /etc/myDaemon.env

But your case is so simple that I also don't see a problem with keeping the arguments in the script.

但是你的情况非常简单,我也没有看到在脚本中保留参数的问题。

#1