【问题标题】:SHOUTcast daemon script not functioning properlySHOUTcast 守护程序脚本无法正常运行
【发布时间】:2013-05-16 16:28:48
【问题描述】:

我有一个在 Ubuntu 上运行的 SHOUTcast 服务器。服务器进程运行良好,但我似乎无法让守护程序脚本正常运行。在几个教程之后,我发现我想出了这个:

#!/bin/sh

CONFIG="/home/apps/shout32/sc_plex.conf"
DAEMON="/home/apps/shout32/sc_serv"

case "$1" in
    start)
        echo "Starting SC..."
        $DAEMON $CONFIG > /dev/null 2>&1 &
        ;;
    stop)
        echo "Stopping SC..."
        kill -9 `ps -C sc_serv -o pid --no-headers`
        ;;
    restart)
        echo "Rebooting SC..."
        kill -9 `ps -C sc_serv -o pid --no-headers`
        $DAEMON $CONFIG > /dev/null 2>&1 &
        ;;
    *)
        echo "usage: service sc32d {start | stop | restart}"
        exit 1
        ;;
esac

但这不起作用。我不知道这意味着什么,所以我开始逐行分解它。如果我删除 /dev/null 的东西——据我所知,这会使程序在后台“静默”运行——我收到这条消息,程序关闭:

root@streams3:/etc/init.d# service sc32d start
Starting SC...
root@streams3:/etc/init.d# 2013-05-21 14:41:50  E       msg:<***>       logger could not open file logs/sc_serv.log
2013-05-21 14:41:50     I       msg:<***>       Logger shutdown

root@streams3:/etc/init.d#
root@streams3:/etc/init.d# ps -C sc_serv
  PID TTY          TIME CMD
root@streams3:/etc/init.d#

我仍在研究 /dev/null 究竟做了什么以及为什么,所以我想用所有 /dev/null 的东西手动运行这些命令,我​​这样做了,这就是我得到某种结果的地方错误代码:

root@streams3:/etc/init.d# /home/apps/shout32/sc_serv /home/apps/shout32/sc_plex.conf > /dev/null 2>&1 &
[2] 2261
root@streams3:/etc/init.d#
[2]-  Exit 255                /home/apps/shout32/sc_serv /home/apps/shout32/sc_plex.conf > /dev/null 2>&1
root@streams3:/etc/init.d# ps -C sc_serv
  PID TTY          TIME CMD

不幸的是,从我所做的简短研究来看,“Exit 225”听起来像是一个包罗万象的错误代码,用于超出可接受的代码范围的代码。

整个问题的有趣部分是:当我导航到 /home/apps/shout32/ 文件夹并在那里运行命令时,没有完整路径......该死的东西有效:

root@streams3:/home/apps/shout32# ./sc_serv sc_plex.conf > /dev/null 2>&1 &
[2] 2245
root@streams3:/home/apps/shout32#
root@streams3:/home/apps/shout32# ps -C sc_serv
  PID TTY          TIME CMD
 2245 pts/0    00:00:00 sc_serv

那么,是不是因为脚本文件位于 /etc/init.d/ 而不是应用程序所在的文件夹中,所以出了点问题?据我所知,我遵循已发布教程中的每一步,在 Ubuntu 中设置 SHOUTcast,然后制作守护进程......我认为我没有错过任何内容。我有一种感觉,解决方案要么是盯着我的脸,要么是某种晦涩难懂的权限,这让我有点不知所措。

但任何帮助将不胜感激!


因此,根据下面的答案,我在脚本的 START 命令中添加了 cd /home/apps/shout32/,还添加了 pwd 和 ls... 以查看我们是否可以消除脚本无法执行的事实找到 /log/ 目录。

所以现在我的脚本是:

CONFIG="/home/apps/shout32/sc_plex.conf"
DAEMON="/home/apps/shout32/sc_serv"

cd /home/apps/shout32/

case "$1" in
        start)
                echo "Starting SC..."
                cd /home/apps/shout32/
                pwd
                ls
                $DAEMON $CONFIG &
                ;;
        stop)
                echo "Stopping SC..."
                kill -9 `ps -C sc_serv -o pid --no-headers`
                ;;
        restart)
                echo "Rebooting SC..."
                kill -9 `ps -C sc_serv -o pid --no-headers`
                $DAEMON $CONFIG &
                ;;
        *)
                echo "usage: service sc32d {start | stop | restart}"
                exit 1
                ;;
esac

我知道了:

admin@streams3:/etc/init.d$ service sc32d start
Starting SC...
/home/apps/shout32
changes.txt     readme.txt                     sc_serv_debug.conf
config_builder  sc_plex.conf                   sc_serv_public.conf
control         sc_serv                        sc_serv_relay.conf
docs            sc_serv2_linux_07_31_2011.tar  sc_serv_simple.conf
logs            sc_serv_basic.conf             tos.txt
admin@streams3:/etc/init.d$ 2013-06-05 17:52:08      E       msg:<***>      logger could not open file logs/sc_serv.log
2013-06-05 17:52:08     I       msg:<***>       Logger shutdown

【问题讨论】:

    标签: shell ubuntu daemon sh shoutcast


    【解决方案1】:

    您的第二个 sn-p 包含 logger could not open file logs/sc_serv.log。因此,它尝试写入文件sc_serv.log,它预期或希望在当前目录 中预期的目录logs 中创建该文件。这也解释了当您首先 cd 到 /home/apps/shout32/ 时它可以工作。我猜有一个文件/home/apps/shout32/logs/sc_serv.log

    你能配置那个文件的位置吗? 您不能在脚本开头添加一些cd ... 吗?

    【讨论】:

    • 是的,在我的 OP 之后我自己的故障排除中,我确定这与 /logs 有关。确实有一个 /home/apps/shout32/logs/sc_serv.log 我尝试更改文件夹/文件上的权限和诸如此类的东西....但是您的建议并没有引起我的注意。我将如何指导脚本像在 X 目录中一样运行?
    • 哦!我明白你在说什么,只需使用 cd /home/apps/shout32.... 启动脚本即可。现在让我试试吧!
    • 我用结果更新了 OP,没有运气。也许我严重误解了你的建议。
    • 不不,你做对了,但显然它没有帮助。也许守护进程cds 进入另一个目录。奇怪的是日志文件是用相对路径指定的,这很不寻常。 $CONFIG 中有什么内容?
    • 带有你永远不知道的相对路径...至少在调试时我会指定一个故障安全绝对路径,如logfile=/tmp/sc_serv.log
    猜你喜欢
    • 1970-01-01
    • 2011-08-13
    • 1970-01-01
    • 2021-10-27
    • 2014-07-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多