[BUG] Webcam setup is skipped on every start after the first when /dev persists and mknod is not permitted
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 88/100
Hướng nghiên cứu
Bắt đầu trong khối webcam của init-selkies-config và so sánh bước kiểm tra sự tồn tại của /dev/video0 với khối gamepad ở phía trên. Tái hiện bằng lệnh docker run được cung cấp với --cap-drop=MKNOD, sau đó kiểm tra /run/s6/container_environment/ giữa các lần khởi động để tìm LD_PRELOAD và SELKIES_WEBCAM_ENABLED. Hoàn tất khi quá trình thiết lập webcam chạy trong một lần khởi động lại với một tệp thông thường còn sót lại, đồng thời vẫn giữ nguyên hành vi đối với một thiết bị thực.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
Hello, and thank you for this image. We build a small application image on top of it and found something in the webcam setup that may affect others who run without CAP_MKNOD.
In init-selkies-config, the webcam block runs only when /dev/video0 does not exist:
if [[ -z ${NO_WEBCAM+x} ]] && [[ ! -e /dev/video0 ]] && { mknod /dev/video0 c 81 0 2>/dev/null || touch /dev/video0 2>/dev/null; }; then
Where mknod is not permitted, touch leaves an empty regular file. If the container's /dev survives a restart of the init, the file is still there on the next start, the ! -e test is false and the whole block is skipped. SELKIES_WEBCAM_ENABLED is not set, the sidebar toggle is not shown and the interposer is not added to LD_PRELOAD. The webcam works on the first start and not on any later one.
The gamepad block just above does not have this problem, because it has no existence test and touch succeeds on a file that is already there.
We saw it on a host that runs the image inside a long-lived LXC container and restarts only the service inside it, so /dev (a tmpfs) outlives the restart.
Expected Behavior
The webcam is set up on every start, as the gamepad devices are.
A possible fix: dropping the [[ ! -e /dev/video0 ]] test would make the block behave like the gamepad one, since touch is harmless on an existing file. If the test is there to protect a real device passed in from the host, testing for a character device instead ([[ ! -c /dev/video0 ]]) would keep that and still recover from a leftover file.
Steps To Reproduce
- Start the image without
CAP_MKNODand with a regular file already at/dev/video0, which is what a second start looks like on such a host (command below). - Look at
/run/s6/container_environment/:LD_PRELOADandSELKIES_WEBCAM_ENABLEDare absent. - Repeat without the
touch: both are set.
Environment
- OS: Debian based host, image run inside an LXC container
- How docker service was installed: reproduced with stock Docker on a desktop
CPU architecture
x86-64
Docker creation
docker run --rm --cap-drop=MKNOD \
--entrypoint sh ghcr.io/linuxserver/baseimage-selkies:dev-5e1478e9-ls23 \
-c 'touch /dev/video0; exec /init'
The same line is on master and ubunturesolute today.
Container logs
Nothing is logged for this: the block is skipped silently. State after start:
$ ls -la /dev/video0
-rwxrwxrwx 1 root root 0 ... /dev/video0
$ cat /run/s6/container_environment/LD_PRELOAD
cat: /run/s6/container_environment/LD_PRELOAD: No such file or directory
$ cat /run/s6/container_environment/SELKIES_WEBCAM_ENABLED
cat: /run/s6/container_environment/SELKIES_WEBCAM_ENABLED: No such file or directory
We work around it by removing a regular-file /dev/video0 before /init, so there is no urgency on our side, and we are glad to test a change. Thank you for your work on this.
- Ngôn ngữ chính
- Shell
- Star
- 230
- Fork
- 34
- Merge trung bình
- 2 giờ 1 phút
- Pull request đã merge (30 ngày)
- 1
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của linuxserver/docker-baseimage-selkies
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 35/100
linuxserver/docker-baseimage-selkies#197 · 1 bình luận ·
-
[FEAT] Downloadordner wählenĐang mởenhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
linuxserver/docker-baseimage-selkies#192 · 2 bình luận ·
Tất cả issue của linuxserver/docker-baseimage-selkies
Issue tương tự
-
gdsa opencode: keep-alive cleanup trap fails with 'keepalive_pid: unbound variable'Có thể đã có người làm @darribas đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
-
icon request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100