Linux 在Debian上使用libcurl而不是自动启动的服务？

我已经用C编写并编译了一个守护程序，该程序将在具有root访问权限的后台运行。我的程序使用libcurl偶尔进行一些网络调用。我还编写了一个简单的init.d脚本来管理它的启动和关闭过程。我希望这个服务在引导时自动启动，根据我所做的，我希望它已经在这样做了。但是，我注意到与libcurl相关的日志中有一个错误，因此服务没有自动启动

我的程序位于

/usr/bin/myprog

中，下面的bash脚本位于

/etc/init.d/myprog

：

#!/bin/bash
### BEGIN INIT INFO
# Provides: myprog
# Required-Start: $remote_fs $network $syslog
# Required-Stop: $remote_fs $network $syslog
# Default-Start: 3 4 5
# Default-Stop: 0 1 2 6
# Short-Description: myprog
# Description: My Daemon Program
### END INIT INFO

. /lib/lsb/init-functions

SCRIPT=/usr/bin/myprog
PIDFILE=/var/run/myprog.pid

start() {
    if [ -f $PIDFILE ]; then
        echo "Service is already started"
        return 2
    else
        $SCRIPT
        $RETVAL="$?"
        return "${RETVAL}"
    fi
}

stop() {
    if [ -f $PIDFILE ]; then
        kill $(cat $PIDFILE)
        rm -f $PIDFILE
        return 0
    else
        echo "Service is not running"
        return 2
    fi
}

case "$1" in
    start)
        log_daemon_msg "Starting myprog" "myprog"
        start
        ;;
    stop)
        log_daemon_msg "Stopping myprog" "myprog"
        stop
        ;;
    status)
        status_of_proce "$SCRIPT" "myprog" && exit 0 || exit $?
        ;;
    restart)
        log_daemon_msg "Restarting myprog" "myprog"
        stop
        start
        ;;
    *)
        echo $"Usage: $0 {start|stop|status|restart}" >&2
        exit 3
        ;;
esac

然后我运行了

sudo update rc.d myprog defaults

，创建了以下文件：

• /etc/rc0.d/K01myprog
• /etc/rc1.d/K01myprog
• /etc/rc2.d/K01myprog
• /etc/rc3.d/S02myprog
• /etc/rc4.d/S02myprog
• /etc/rc5.d/S02myprog
• /etc/rc6.d/K01myprog

据我所知，这7个文件中的每一个都是我上面发布的文件的相同副本。基于我所阅读的各种教程和论坛，我认为这就足够了。但是，我的服务在启动时似乎不会自动启动。如果我直接调用

sudo/etc/init.d/myprog start

，那么它会正常启动。但除此之外，它似乎不会启动

---

然后我注意到日志中有一条错误消息，上面写着“curl error:无法解析主机”，即使它引用的特定主机确实有效。因此，我认为它可能试图在libcurl需要的东西准备好之前启动我的应用程序，因此未能启动。同样，如果我手动启动它，它工作正常。如何解决此问题？

如果DNS解析是故障点，请使用IP地址。如果不愿意使用IP地址，请将主机名和IP地址添加到/etc/hosts

您应该使用

dmesg | grep“curl”

并公布实际错误。这里的消息是“无法解析主机：www.xxxxxx.com”。我正在审查实际域，因为它是用于工作的，我不想共享URL，但足以说明URL确实有效。我可以手动运行同一个程序，然后它就可以工作，这一事实进一步证实了这一点。另外，该消息来自我自己的日志（因为我正在设置CURLOPT_ERRORBUFFER并记录失败）；当我运行dmesg命令时，您建议它返回空白。但是我不认为DNS解析是真正的失败点，因为我可以手动运行相同的代码，然后它就可以正常工作。似乎它试图过早地运行它，而底层系统还没有准备好DNS解析（或者别的什么）。很容易地尝试我的建议并确定。在考虑到DNS解析到Amazon Server并且IP可以定期改变的情况下，这在商业情况下是不实际的。