Deleted fragment files keep showing up in the error log of a new installation
June 19, 2021 09:58PM
I have a real strange one that I need help with.

Here is the scenario:
NGINX installed on linux mint (i know, not the best choice, but it will be demoted from server to workstation real soon).
A NoIP DNS pointing at the linux mint machine.
A 7 terabyte drive for the fragments, as the main drive is an SSD.
I could send broadcasts (rtmp) to NGINX, and video players could receive the stream via HLS (.m3u8).
And then there was a hardware failure.

I had to reinstall linux mint.
I compiled NGINX the same way as originally.
I had the same .conf file to use.

After reinstallation, the IP addresses are all the same as before.

I had deleted the remaining fragments from the media drive. But, I left the file structure there so as to match the conf file.

NGINX checks out with the -t command.

But no rtmp broadcasts are received without error. OBS and others broadcasting software give no message but to say it can't connlect to the server.

An ffmpeg stream from a shell on the same machine simply says, "input/output error" .

I took a look at the error.log for NGINX and it is trying to process the last remaining fragments that used to be on that drive. They aren't there, and it is a completely virgin installation of linux and nginx.

I have no idea how NGINX would even know about the fragments.

Here is a sampling of the error.log

2021/06/19 21:48:13 [error] 12557#0: *6 open() "/media/henry/MINE/hls/CH1-NVT.m3u8" failed (13: Permission denied), client: 66.176.4.141, server: localhost, request: "GET /hls/CH1-NVT.m3u8 HTTP/1.1", host: "novirus.ddns.net"
2021/06/19 21:48:13 [error] 12557#0: *8 open() "/media/henry/MINE/hls/CH2-SWC.m3u8" failed (13: Permission denied), client: 66.176.4.141, server: localhost, request: "GET /hls/CH2-SWC.m3u8 HTTP/1.1", host: "novirus.ddns.net"
2021/06/19 21:48:13 [error] 12557#0: *7 open() "/media/henry/MINE/hls/CH2-SWC.m3u8" failed (13: Permission denied), client: 66.176.4.141, server: localhost, request: "GET /hls/CH2-SWC.m3u8 HTTP/1.1", host: "novirus.ddns.net"
2021/06/19 21:48:13 [error] 12557#0: *5 open() "/media/henry/MINE/hls/CH1-NVT.m3u8" failed (13: Permission denied), client: 66.176.4.141, server: localhost, request: "GET /hls/CH1-NVT.m3u8 HTTP/1.1", host: "novirus.ddns.net"

Permissions are all ok. The permission message doesn't seem to make sense because there is nothing on the drive to open.

Here is a part of the access.log

66.176.4.141 - - [19/Jun/2021:21:50:55 -0400] "GET /hls/CH2-SWC.m3u8 HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 OPR/76.0.4017.177"
66.176.4.141 - - [19/Jun/2021:21:50:55 -0400] "GET /hls/CH2-SWC.m3u8 HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 OPR/76.0.4017.177"
66.176.4.141 - - [19/Jun/2021:21:50:55 -0400] "GET /hls/CH1-NVT.m3u8 HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 OPR/76.0.4017.177"
66.176.4.141 - - [19/Jun/2021:21:50:55 -0400] "GET /hls/CH1-NVT.m3u8 HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36 OPR/76.0.4017.177"

I don't know enough to know if these are errors or just events. But, there is nothing to GET.

No other logs are generated.

I am assuming that new streams aren't being received by NGINX because somehow it is being fed stream data from just before the crash, and it's choking.

Any help would be greatly appreciated. I'm kind of stumped on this one.

Thanks, in advance.

Gar
To follow up, I just changed the DNS and that flow of old fragments or .m3u8 files or requests stopped.

It didn't solve the problem. But, I realized that the secondary drive may have had the same user name as ownership but the underlying userid number was different, hence the permission error. I had to delete the folders and recreate them.

All is well. Sorry if you spent any time on this.

Gar
Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 189
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready