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.

我的猜测是，有时它关闭旧的山顶可能不会删除。

有没有一种方法可以手动删除此Mountpoint，或者有其他方法可以解决此问题？

非常感谢。

Answer 1

我有时有同样的问题。无论出于何种原因，第一个实例尚未干净地退出，并且仍在安装点的ADDR/端口组合上聆听，从而阻止了新实例与其绑定。您可以在不重新启动的情况下修复它，需要找到引起问题的过程，然后杀死它。

例如，假设您的坐骑是在端口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将TERSE选项投入混合物中，告诉lsof倾倒我们不需要的位，只给我们我们感兴趣的信息，我们要杀死的PID：p> lsof -ti:8800

30511

我们的命令现在仅返回PID。完美，让我们用它来：

lsof -ti:8800 | xargs kill -9

工作完成。lsof -ti:8800现在什么都不返回，液体Soap/iCecast/任何应该正确启动。