Liquidsoap 1.3.1 — 使用中的挂载点

Question

当我关闭我的 Icecast 服务器时，偶尔会出现重新启动它的问题，这迫使我重新启动我的计算机。

日志如下所示

14:52:22 soap.1 | started with pid 9817
14:52:22 soap.1 | Warning: ignored expression at line 12, char 20-96.
14:52:22 soap.1 | 2017/09/12 14:52:22 >>> LOG START
14:52:22 soap.1 | 2017/09/12 14:52:22 [main:3] Liquidsoap 1.3.1 (git://github.com/savonet/liquidsoap.git@3adeff73df0cd369401c7b46caaab058ef80880b:20170608:111503)
14:52:22 soap.1 | 2017/09/12 14:52:22 [main:3] Using: bytes=[distributed with OCaml 4.02 or above] pcre=7.2.3 dtools=0.3.3 duppy=0.6.0 duppy.syntax=0.6.0 cry=0.5.0 mm=0.3.0 xmlplaylist=0.1.4 lastfm=0.3.1 ogg=0.5.1 opus=0.1.2 speex=0.2.1 mad=0.4.5 flac=0.1.2 flac.ogg=0.1.2 dynlink=[distributed with Ocaml] lame=0.3.3 gstreamer=0.2.2 fdkaac=0.2.1 theora=0.3.1 bjack=0.1.5 alsa=0.2.3 ao=0.2.1 samplerate=0.1.4 taglib=0.3.3 camomile=0.8.5 faad=0.3.3 soundtouch=0.1.8 portaudio=0.2.1 pulseaudio=0.1.3 ladspa=0.1.5 dssi=0.1.2 lo=0.1.1
14:52:22 soap.1 | 2017/09/12 14:52:22 [gstreamer.loader:3] Loaded GStreamer 1.2.4 0
14:52:22 soap.1 | 2017/09/12 14:52:22 [frame:3] Using 44100Hz audio, 25Hz video, 44100Hz master.
14:52:22 soap.1 | 2017/09/12 14:52:22 [frame:3] Frame size must be a multiple of 1764 ticks = 1764 audio samples = 1 video samples.
14:52:22 soap.1 | 2017/09/12 14:52:22 [frame:3] Targetting 'frame.duration': 0.04s = 1764 audio samples = 1764 ticks.
14:52:22 soap.1 | 2017/09/12 14:52:22 [frame:3] Frames last 0.04s = 1764 audio samples = 1 video samples = 1764 ticks.
14:52:22 soap.1 | 2017/09/12 14:52:22 [threads:3] Created thread "generic queue #1".
14:52:22 soap.1 | 2017/09/12 14:52:22 [threads:3] Created thread "generic queue #2".
14:52:22 soap.1 | 2017/09/12 14:52:22 [threads:3] Created thread "non-blocking queue #1".
14:52:22 soap.1 | 2017/09/12 14:52:22 [threads:3] Created thread "non-blocking queue #2".
14:52:22 soap.1 | 2017/09/12 14:52:22 [ogr:3] Connecting mount ogr for source@localhost...
14:52:22 soap.1 | 2017/09/12 14:52:22 [ogr:2] Connection failed: 403, Mountpoint in use (HTTP/1.0)
14:52:22 soap.1 | 2017/09/12 14:52:22 [ogr:3] Will try again in 3.00 sec.
14:52:22 soap.1 | strange error flushing buffer ... 
14:52:22 soap.1 | strange error flushing buffer ... 
14:52:22 soap.1 | 2017/09/12 14:52:22 [threads:3] Created thread "wallclock_main" (1 total).
14:52:22 soap.1 | 2017/09/12 14:52:22 [clock.wallclock_main:3] Streaming loop starts, synchronized with wallclock.
14:52:22 soap.1 | 2017/09/12 14:52:22 [fallback_9219:3] Switch to sine_9218.

我的猜测是，有时当它关闭时，旧的挂载点可能不会被删除。

有没有办法手动删除这个挂载点，或者有其他方法解决这个问题？

非常感谢。

Answer 1

我有时也会遇到同样的问题。无论出于何种原因，第一个实例都没有完全退出，并且仍在侦听挂载点的 addr/port 组合，从而阻止新实例绑定到它。无需重启即可修复，需要找到导致问题的进程，然后将其杀死。

例如，假设您的挂载点正在侦听端口 8800，您可以使用 lsof 命令来识别旧进程。添加-i 选项并指定要为其返回结果的接口/端口，您将得到如下结果：

lsof -i:8800

COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
liquidsoa 30511 liquid   20u  IPv4 947691      0t0  TCP 192.168.1.5:8800 (LISTEN)

所以这里有问题的 pid 将是 30511，如果你杀死了 kill -9 30511，那么liquidsoap 应该会正常重启。

这就是涵盖的基本概念，现在让我们把它变成一个单行。

我们可以添加t 以将简洁的选项加入其中，告诉lsof 转储我们不需要的位，只给我们感兴趣的信息，我们想要的pid杀死：

lsof -ti:8800

30511

我们的命令现在只返回 pid。完美，让我们来管道吧：

lsof -ti:8800 | xargs kill -9

工作完成。 lsof -ti:8800 现在应该什么都不返回，并且liquidsoap/icecast/whatever 应该可以正常启动。