Camera device nodes disappear when a second application starts

A camera can work in either application alone yet fail when both run together. The first task is to establish whether its Linux device nodes actually disappear or merely become unavailable for acquisition. Those symptoms point to different causes. This troubleshooting procedure separates enumeration, ownership and driver changes, then builds a reproducible test with kernel evidence. It applies to systems combining a capture service, inspection application, recorder or inference process.

1. Separate missing nodes from unavailable streams

Starting another application does not normally remove a device node simply because the camera is busy. Depending on the driver, competition can instead prevent opening the device, changing its configuration or starting a stream. Actual node removal needs a different investigation.

Compare the filesystem and application messages at the same instant. Do not use an application's empty camera list as proof that Linux removed the device.

If Linux still exposes the device but the application cannot discover it, follow the narrower SDK discovery diagnostic. Do not replace that investigation with repeated reconnects.

2. Record identity and capabilities before launching either application

Stop both applications normally, including background capture services. Record the baseline from the host environment where the camera is attached:

uname -r
ls -l /dev/video* /dev/media*
v4l2-ctl --list-devices
lsusb -t

These commands require the corresponding utilities to be installed. An unmatched device wildcard may produce a missing-file message; retain that message as evidence of the current state.

For each relevant video node, inspect its advertised capabilities:

v4l2-ctl --device=/dev/video0 --all
udevadm info --query=property --name=/dev/video0

Treat /dev/video0 as an example path, not a permanent camera identity. Record the actual path, physical connection and any available serial identifier.

One physical camera may expose several interfaces. A video node can provide image capture or metadata; its number does not establish its purpose. Use capabilities and supported formats rather than assuming that adjacent node numbers represent interchangeable streams. The stream-selection diagnostic explains how to distinguish the required image endpoint.

If applications run in different containers or execution environments, compare their device visibility separately. The container device-mapping checks cover that branch without confusing it with host-level removal.

3. Check ownership without forcing another process to release it

When the node remains present, inspect which processes have it open:

fuser -v /dev/video0
lsof /dev/video0

Repeat for the relevant nodes. Process information can be incomplete when your account lacks permission to inspect another process. Use approved administrative access when needed; an empty listing is not always proof that nobody owns the device.

An open file is evidence of access, not proof that the process is actively streaming. Also, a userspace acquisition library may access the underlying USB device directly, so checking video nodes alone is not exhaustive.

Close identified applications through their normal shutdown procedure. Retest after they exit. Do not terminate unrelated services, force interface release or change permissions broadly just to make a test pass.

For access-denied errors, compare the identities and groups used by interactive applications and services. Follow the device permission checks instead of making camera nodes writable by every user.

4. Run an isolated acquisition matrix

Use application A and application B as labels in your test record. Keep resolution, pixel format and requested frame rate unchanged wherever both applications support the same configuration.

1. Start A alone, capture for 30 seconds, then close it normally.
2. Confirm that device nodes and the baseline camera identity remain present.
3. Start B alone with the same observation period, then close it normally.
4. Start A, confirm stable capture, and then start B.
5. Restore the baseline and reverse the order: B first, then A.
6. Repeat a failing sequence three times while recording the exact actions and event times.

These durations and repetition counts are diagnostic starting points, not production acceptance criteria. Extend them if the failure is intermittent.

Record whether failure happens during discovery, device opening, configuration, stream start or shutdown. A failure during discovery suggests a different interaction from one triggered by the first image request.

Next, replace one full application with the manufacturer's documented minimal capture utility. Then test the other application the same way. This removes middleware, inference and display processing from the comparison without assuming any particular component is responsible.

If both minimal clients work independently but fail together, investigate supported ownership before changing image-processing code.

5. Capture kernel and device events during the failure

Start observation before launching either application. In separate terminals, run:

journalctl -k -b -o short-monotonic --follow

udevadm monitor --kernel --udev --property

Access to kernel logs may require approved administrative permissions. Save the relevant output, along with each application's own logs, using your site's normal diagnostic procedure.

Look for the sequence surrounding the failure: USB disconnect, reset, driver unbind, device removal, driver registration and device addition. Preserve a few seconds before and after the event rather than copying only the final error.

Kernel and udev messages can describe the same change at different processing stages. Application timestamps may use a different clock, so record launch times and the clock format rather than assuming every timestamp is directly comparable.

For example, a hypothetical record might show A capturing, B starting 10 seconds later, and a kernel device-removal event immediately afterward. That establishes timing, not causation. Repeat the sequence and check whether removal also occurs when B runs alone.

If the USB device remains enumerated while video nodes disappear, investigate interface ownership and driver state. If the USB device itself disconnects, investigate resets and connection conditions as well. Neither observation alone identifies a defective camera.

6. Narrow the driver, library and configuration boundary

Build a version record before updating anything. Include the kernel, camera driver, acquisition library, application package, selected backend and camera firmware version reported by the documented utility.

A userspace USB backend can claim interfaces differently from a kernel video backend. In some implementations, claiming an interface involves detaching its kernel driver. That can remove associated video nodes even though the USB device remains connected. Confirm this behavior in the manufacturer's documentation; do not assume it explains every disappearance.

Check these boundaries in order:

• Backend selection: Determine whether both applications use kernel video capture, a userspace USB path or different acquisition transports.
• Library loading: Compare the libraries actually loaded by each application, not just the package versions installed system-wide.
• Startup behavior: Check whether either application resets the camera or reconfigures interfaces during initialization.
• Shutdown behavior: Determine whether normal closure restores the original nodes without reconnecting the camera.
• Supported combinations: Verify the documented kernel, library and firmware compatibility before changing versions.

Use software, firmware and documentation only from the manufacturer or its distributors. Change one component at a time and retain a documented recovery path. Rebuilding a library with another backend is appropriate only when that backend and camera combination are supported.

7. Use one acquisition owner when independent access is unsupported

If independent simultaneous acquisition is not documented, the usual design is one process owning the camera and publishing images to downstream consumers. Inspection, recording and inference then receive frames without competing for hardware configuration.

The acquisition-session architecture explainer is the closest companion to this decision. Hardware ownership and application consumption are separate responsibilities, even when the system contains only one camera.

Sharing frames introduces its own bandwidth and latency budget. For an illustrative uncompressed, single-plane image with tightly packed rows:

For a 1920 × 1080 image using 1 byte per pixel:

• Frame payload = 1920 × 1080 × 1 = 2,073,600 bytes.
• At 30 frames/s, payload rate = 2,073,600 × 30 = 62,208,000 bytes/s, or about 62.2 MB/s.
• With four complete frames ahead at a 30 frames/s processing rate, queue waiting time is approximately 4 ÷ 30 = 0.133 seconds.

Actual memory traffic can be higher because of copies, row padding and format conversion. Define bounded queues and an explicit drop policy. For inspection records, preserve frame identifiers and timestamps so consumers cannot silently associate different images with the same result.

8. Check compatibility before selecting replacement hardware

Changing cameras or hosts is not the first fix for an ownership conflict. An interface label does not establish Linux backend support, simultaneous-client behavior or compatibility with a particular application.

For an acquisition review, the LS-CMR-0166 is a USB3 area scan camera. Confirm the required Linux acquisition path before selecting it.

The LS-CMR-0053 is a GigE area scan camera. Its transport differs, but that alone does not establish support for independent simultaneous applications.

Compare the required interfaces in the area scan cameras category and camera finder. For vision controllers, confirm operating-system support, acquisition-library compatibility and camera-port behavior before ordering.

Prepare a compatibility checklist covering the supported operating system, driver, transport, pixel formats, triggering requirements and ownership model. Request confirmation of the exact combination you intend to deploy. A camera appearing in a discovery list is not enough evidence of sustained acquisition support.

9. Verify the fix and prepare a useful escalation package

Repeat the same acquisition matrix after each change. A fix should explain the observed symptom, not merely make it disappear once.

• Node identity: Confirm that the intended camera remains identifiable through startup and shutdown.
• Ownership: Verify which process opens the hardware and which processes consume shared images.
• Startup order: Repeat both launch orders unless the design explicitly requires one documented sequence.
• Restart recovery: Close and restart each application without leaving a stale acquisition session.
• Frame integrity: Check frame identifiers, timestamps and incomplete-frame counters where available.
• Logs: Confirm that the previously observed removal, reset or acquisition error no longer occurs during the same test.
• Duration: Extend testing to representative operating conditions, not just a short bench run.

If nodes remain present but capture freezes, switch to the callback and buffer-queue diagnostic. Continuing to investigate enumeration would target the wrong failure.

For escalation, provide the baseline device map, version record, isolated-test matrix, kernel event excerpt and minimal reproduction. Remove credentials and unrelated sensitive information before sharing logs.

Use the camera configurator when your acquisition requirements are established, or contact the applications team with that evidence before choosing replacement hardware.