search

orcasound / orcanode

Software for live-streaming and recording lossy (AAC) or lossless compressed audio (HLS, DASH, FLAC) via AWS S3 buckets. :star:
GNU Affero General Public License v3.0
34 stars 12 forks source link

Intermittent failure of s3fs to mount /mnt directories because they are non-empty #9

Open scottveirs opened 6 years ago

scottveirs commented 6 years ago

First noticed this today (5/22/18) when Orcasound player failed to load latest HLS stream directory. Though the container restarts with ffmpeg and rsync running, s3fs fails to start as expected, so no files get transferred to S3 bucket.

LogDNA suggests it has happened intermittently since 5/17/22:


May 17 11:31:19 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-archive-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 17 16:30:56 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-archive-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 17 17:30:56 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-archive-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 18 02:30:58 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-streaming-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 18 06:31:47 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-streaming-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 19 09:30:57 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-streaming-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.
May 19 22:31:44 rpi_seattle orcanode_streaming_1 err s3fs: MOUNTPOINT directory /mnt/dev-archive-orcasound-net/ is not empty. if you are sure this is safe, can use the 'nonempty' mount option.```

Not sure why the error wasn't logged this morning. The latest datetime stamped directory in the S3 streaming bucket was written around 9:30. Previous directories formed and were populated successfully at 8:30, 7:30, 6:30... and there doesn't look to be anything suspicious in the m3u8 or .ts files within the previous (8:30) directory.
scottveirs commented 6 years ago

Consider adding -o nonempty to s3fs calls per this Stackoverflow thread?

mcshicks commented 3 years ago

We should be able to close this when we move master to only have s3_upload method and deprecate s3fs