@jess
I am having this same issue and I have disable the ‘PrivateTMP’ feature. However, let me note that this functionally is enable by default each time a new process or service is created with yum. I have not figured out how to disable it from doing that on installation of new services. This is how I disabled it on my system.
First, edit the file with your favorite editor vi, nano or whatever you prefer.
# nano /usr/lib/systemd/system/kaltura-nginx.service
Find this line in the file
PrivateTmp=true
then change it to this
PrivateTmp=false
then run these commands
# systemctl daemon-reload
# systemctl restart kaltura-nginx
The location of this file might differ from OS to OS but my current OS is CentOS 7.1.3 and even after doing this change I can see the files in the temp directories:
/var/tmp/hlsme
/var/tmp/dashme
However, my files are still not streaming. I have tried to stream using OBS from my desktop and using my server CLI but I am not able to playback the stream from Kaltura HTML5 player or my VLC player from my desktop. I getting the following error when using VLC:
Your input can’t be opened
VLC is unable to open the MRL ‘http://cdn.mydomain.com:88/hlsme/stream.m3u8’. Check the log for details.
Now in my kaltura_nginx_errors.log I am seeing both the OBS stream and the CLI based stream starting and stopping.
2017/07/27 01:28:01 [info] 19011#19011: *1 exec: starting managed child ‘on’, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:01 [notice] 19011#19011: signal 17 (SIGCHLD) received
2017/07/27 01:28:01 [notice] 19011#19011: unknown process 11248 exited with code 1
2017/07/27 01:28:01 [info] 19011#19011: *1 exec: child 11248 exited; ignoring, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:01 [info] 19011#19011: *1 exec: terminating child 11248, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:01 [info] 19010#19010: *2 exec: starting managed child ‘on’, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:01 [notice] 19010#19010: signal 17 (SIGCHLD) received
2017/07/27 01:28:01 [notice] 19010#19010: unknown process 11249 exited with code 1
2017/07/27 01:28:01 [info] 19010#19010: *2 exec: child 11249 exited; ignoring, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:01 [info] 19010#19010: *2 exec: terminating child 11249, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [info] 19011#19011: *1 exec: starting managed child ‘on’, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [notice] 19011#19011: signal 17 (SIGCHLD) received
2017/07/27 01:28:06 [notice] 19011#19011: unknown process 11254 exited with code 1
2017/07/27 01:28:06 [info] 19011#19011: *1 exec: child 11254 exited; ignoring, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [info] 19011#19011: *1 exec: terminating child 11254, client: MY_DESKTOP_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [info] 19010#19010: *2 exec: starting managed child ‘on’, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [notice] 19010#19010: signal 17 (SIGCHLD) received
2017/07/27 01:28:06 [notice] 19010#19010: unknown process 11255 exited with code 1
2017/07/27 01:28:06 [info] 19010#19010: *2 exec: child 11255 exited; ignoring, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
2017/07/27 01:28:06 [info] 19010#19010: *2 exec: terminating child 11255, client: MY_SERVER_IP, server: MY_KALTURA_SERVER_IP:1935
You will note from my log that I set the IP used for Kaltura and NGINX to a specific IP and not the default host IP address. This helps to avoid conflicts with other services such as Red5, Wowza or simular that usually generate port conflicts and require use of non-standard ports.
I check the premissions for the tmp folders used for hlsme and dashme and they are:
# ls -al /var/tmp/
total 44
drwxrwxrwt. 11 root root 4096 Jul 26 22:23 .
drwxr-xr-x. 21 root root 4096 Jul 21 13:31 ..
drwx------. 2 kaltura root 4096 Jul 27 01:41 dashme
drwx------. 2 kaltura root 4096 Jul 27 01:41 hlsme
However, the files in the folder are owned and in the ‘kaltura’ usergroup as well as own by the same group.
This stream is from ffmpeg using CLI
-rw-r--r--. 1 kaltura kaltura 27072 Jul 27 01:41 frontdoor-3225.ts
-rw-r--r--. 1 kaltura kaltura 27072 Jul 27 01:41 frontdoor-3226.ts
-rw-r--r--. 1 kaltura kaltura 9588 Jul 27 01:41 frontdoor-3227.ts
-rw-r--r--. 1 kaltura kaltura 571 Jul 27 01:41 frontdoor.m3u8
This stream is from OBS using my desktop
-rw-r--r--. 1 kaltura kaltura 2874708 Jul 27 01:41 stream-965.ts
-rw-r--r--. 1 kaltura kaltura 2860044 Jul 27 01:41 stream-966.ts
-rw-r--r--. 1 kaltura kaltura 1492156 Jul 27 01:41 stream-967.ts
-rw-r--r--. 1 kaltura kaltura 510 Jul 27 01:41 stream.m3u8
As you can see the files are being created. Now, the big difference between trying to playback from my compute and Kaltura CE is that my computer basically returns an error saying no stream is available at the URL. Kaltura HTML5 player actual keeps trying to connect and play the stream but just spins non-stop and when I stop the stream completely it basically saying no broadcast is available. So this implies it can detect the stream but is not playing it.
I check the stream from Kaltura HTML5 player using the internal generated page too and view the page with my web developer tool to search for errors. There was only one error which was mixed content error saying that the URL ‘http://cdn.mydomain.com:88/hlsme/stream.m3u8’ was blocked.
Now, at this point I tried changing the url to ‘https://cdn.mydomain.com:8443/hlsme/stream.m3u8’ and got nothing in VLC and Kaltura HTML5 player display the “No broadcast is available” message. Since Kaltura HTML5 player is detecting data or stream is being recieved and VLC appears to be rejected or timesout I am wondering if this is an issue with permissions or something related to the proper configuration of the NGINX so it properly access the assigned tmp folder for the hls and dash files.
Now, I also check for SSL errors but there is no actually NGINX ssl error log for Kaltura even configured so I am not able to troubleshoot the same way to resolve issues related to the content not loading via the SSL port on NGINX.
