Open j1elo opened 11 months ago
We ran into a similar problem
It seems worth checking the backup folder on application startup as it is done with cpu cost
2024-01-26T06:04:44.211Z DEBUG egress sink/file.go:72 removing temporary directory {"nodeID": "NE_cuiBEQs2wyZS", "handlerID": "EGH_KkLSksr5NuNW", "clusterID": "", "egressID": "EG_Fn6z3ZbmtRYf", "path": "/home/egress/tmp/EG_Fn6z3ZbmtRYf/"}
2024-01-26T06:04:44.276Z WARN egress service/handler.go:229 egress failed {"nodeID": "NE_cuiBEQs2wyZS", "handlerID": "EGH_KkLSksr5NuNW", "clusterID": "", "egressID": "EG_Fn6z3ZbmtRYf", "egressID": "EG_Fn6z3ZbmtRYf", "requestType": "room_composite", "outputType": "file", "error": "rename /home/egress/tmp/EG_Fn6z3ZbmtRYf/2024-01-26T045922.mp4 /stucked/fa5cc19b-6c7e-4f18-95b6-695fc0bc5b1c/2024-01-26T045922.mp4: no such file or directory"}
Describe the bug
The backup feature (
backup_storage
) fails if the destination path is in a different mount point than the files (e.g. a different Docker bind mount or volume).This happens because os.Rename as used here is just a call to the renameat syscall, which doesn't allow moving across partitions.
The error is
EXDEV
, which Go translates into "invalid cross-device link". See os.Rename between different partitions:Thus I guess the error could be captured and a different move method attempted, kind of
But as it is right now, such a move will cause the error posted below, regardless of having correct write permissions on the destination path.
Egress Version https://hub.docker.com/r/livekit/egress/ v1.8.0
Egress Request N/A
Additional context
/backup_storage/
is a Docker bind-mount to the host system, where recording backups should be stored.Logs