我创建了一个Linux守护进程（使用C语言），通过UDP将某些信息发送到另一台计算机。它当然需要远程IP地址和端口号。我将此守护程序存储在/usr/local/bin/中，并且还在/etc/init.d/中创建了一个脚本以启动|停止|重新启动守护程序。
到目前为止，IP地址和端口号直接由脚本传递给守护程序。例如，脚本的start（）部分如下所示：
start() {
/usr/local/bin/lvsload_udp_s 192.168.122.25 47239
}
因此，当远程IP和/或端口号发生变化时，我必须修改我的脚本，而不是修改某些配置文件。我知道这是一种不好的做法。
将参数传递给我的守护进程的最佳方法是什么？感谢
答案 0 :(得分：6)
为什么你认为命令行参数不好？
配置文件是额外的工作，因为您需要解析它们。继续您的示例，修改配置文件=修改一个文件。修改脚本=修改一个文件。当你只有少量的论点时，似乎没什么区别。你甚至可以将参数粘贴到脚本顶部的变量中，这使得它几乎就像一个配置文件:-)有些脚本甚至会提供这样的“变量设置脚本”，所以它看起来真的像配置文件。
如果你能找到命令行参数不好的原因，那么你很可能也知道要使用什么。另一方面，如果您甚至无法解释为什么命令行参数不好，那么使用它们可能没有错...
答案 1 :(得分：2)
问：到目前为止，IP地址和端口号都传递给了 守护进程，直接......我知道这是一种不好的做法。
答：你为什么认为这是“不好的做法”????
“良好做法”包括：
“干”（不要重复自己 - 将数据存储在一个且只有一个地方）
“吻”（保持简单，愚蠢）
我会说一个脚本中的一个参数（命令行IP地址）（你的init.d启动脚本）很好地遵循这两个原则：）
... IMHO
PS：
如果你真的认为配置文件是合适的 - 如果有许多复杂的配置数据需要在启动时解析，那么两个合适的位置将是：
将配置文件存储在/ etc（并将您的应用程序存储在/ usr / local / bin中）
...或..
将配置文件存储在应用程序的安装目录中（并可能定义一个全局环境变量以指向安装目录）
答案 2 :(得分：2)
这是特定于发行版的。例如，在debian上，约定是/etc/init.d/foo包含类似“source / etc / default / foo”的行。该文件仅包含环境变量，例如DAEMON_ARGS = “ - 远程IP = 192.168.0.1”
如果使用debhelper构建debian包，它将自动为您创建此结构。我确信也有类似的工具来创建“标准”RPM。
答案 3 :(得分：1)
使用环境变量：
// include stdlib for getenv
port = getenv("MY_DAEMON_PORT");
host = getenv("MY_DAEMON_HOST");
// convert port to integer...
我记得在init.d启动的流程中，这有点传统。
由于您已经提到过您正在使用Ubuntu，请查看/etc/environment - 请参阅docs。但正如有人已经提到过这取决于你的系统/发行版;另一种方法是将环境变量保持在例如/etc/myDaemon.env，然后从您的init脚本中获取：
. /etc/myDaemon.env
但是你的情况非常简单，我也没有看到在脚本中保留参数的问题。