Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

dcvagent SIGSEGV in PulseAudio teardown on Linux virtual sessions (DCV 2025.0); is [audio] enabled supported?

0

Disclosure - this was created with the help of claude.ai as it was a non-trivial problem to find and debug so I had it create this summary.

dcvagent SIGSEGV in PulseAudio teardown on Linux virtual sessions; [audio] enabled is undocumented

Summary

On Amazon DCV 2025.0 (Linux virtual sessions), the per-session dcvagent process segfaults (SIGSEGV) inside the PulseAudio client-connection teardown path. Setting [audio] enabled=false in dcv.conf stops the crash for newly created sessions, but that key is not documented in the DCV parameter reference, and because [audio] is a session-context parameter it cannot be applied to already-running sessions. I am asking AWS to (1) confirm/document the correct supported way to disable DCV audio on Linux, and (2) advise whether the underlying teardown crash is a known issue and whether any supported mechanism exists to apply the setting to a running session.

Environment

  • Amazon DCV Server 2025.0 (build 2025.0-20103)
  • Rocky Linux 8.10, x86_64
  • Session type: virtual (headless; no GPU / no console session). Users self-create their own virtual sessions.
  • Desktop: GNOME
  • PulseAudio 14.x (system default on RHEL 8 / Rocky 8; libpulsecommon-14.0.so)
  • Sessions are long-lived (users keep a single virtual session open for weeks to months).

Symptom

Recurring, non-deterministic crashes of /usr/libexec/dcv/dcvagent with signal 11 (SIGSEGV). Observed multiple times per day across a fleet of similarly configured hosts. The crash correlates with teardown of the agent's PulseAudio connection (it appears on the live glib main loop, consistent with a connection being dropped during an active agent rather than at clean process exit). Many benign session open/close events also produce dcvagent exits, but these SIGSEGVs produce real core dumps with the stack trace below.

Backtrace (crashing thread)

#0  glib_io_free                         (libpulse-mainloop-glib.so.0)
#1  _dbus_watch_list_remove_watch        (libdbus-1.so.3)
#2  free_watches                         (libdbus-1.so.3)
#3  socket_disconnect                    (libdbus-1.so.3)
#4  _dbus_transport_disconnect.part.5    (libdbus-1.so.3)
#5  _dbus_connection_close_possibly_shared_and_unlock (libdbus-1.so.3)
#6  pa_dbus_wrap_connection_free         (libpulsecommon-14.0.so)
#7  context_free                         (libpulse.so.0)
#8  <libpulse_binding::context::Context as core::ops::drop::Drop>::drop (libdcv.so)
#9  core::ptr::drop_in_place<dcvrust::server::pulseaudio_utils::PulseConnection> (libdcv.so)
#10 glib::main_context_futures ... spawn_local_with_priority {{closure}} (libdcv.so)
#11 glib::main_context_futures::TaskSource::dispatch (libdcv.so)
#12 g_main_dispatch                       (libglib-2.0.so.0)
#13 g_main_context_iterate_unlocked       (libglib-2.0.so.0)
#14 g_main_context_iteration              (libglib-2.0.so.0)
#15 dcv_application_run                   (libdcv.so)
#16 main                                  (dcvagent)

Signal: 11 (SIGSEGV). All other threads are idle (parked worker pools, ppoll, grabber sleeping). The fault is isolated to the PulseAudio/dbus/glib teardown, not broader memory corruption.

Interpretation: dcvagent constructs a dcvrust::server::pulseaudio_utils::PulseConnection. When that object is dropped, it frees the pulse Context, which tears down the underlying dbus connection, which frees the glib IO watch, and the segfault lands in glib_io_free. This looks like a use-after-free or double-free in the pulse/dbus/glib teardown interaction inside libdcv.so.

Workaround found (and its limits)

Adding the following to /etc/dcv/dcv.conf prevents the crash on sessions created after the change:

[audio]
enabled=false

Verified on a treated host: a freshly created session's dcvagent builds no PulseAudio client connection. lsof/ss -xp on the agent PID show no socket to /run/user/<uid>/pulse/native (the PulseAudio .so files are still linked into the process, but no connection object is constructed, so there is no teardown to crash on). A host carrying this setting across a reboot logged zero dcvagent SIGSEGVs over a full day of active multi-user sessions, while comparable untreated hosts logged many.

Note: OS-level attempts to suppress PulseAudio do not prevent this crash. Masking the systemd user unit has no effect because the daemon is launched via XDG autostart (/etc/xdg/autostart/pulseaudio.desktop) on GNOME login, not via the unit. dcvagent still connects to the per-user daemon and still crashes on teardown. Only [audio] enabled=false in dcv.conf stops the client connection.

Problem 1: [audio] enabled is undocumented

The Amazon DCV Server parameter reference documents only two keys under [audio]: avsync-support and source-channels. There is no documented enabled (or audio-enabled) key for the DCV [audio] section. The enabled=false value appears to work empirically, but because it is undocumented its support status and exact semantics are unspecified.

Requests:

  • Please confirm whether [audio] enabled=false is a supported way to disable DCV audio on Linux virtual sessions, and if so, document it in the parameter reference.
  • If it is not the supported key, please state the correct supported parameter to disable DCV's audio bridge on Linux.

Problem 2: cannot apply to running sessions; long-lived sessions stay exposed

[audio] is a session-context parameter ("loaded when the session is created; if updated, the new value is loaded for subsequent sessions"). The running dcvagent does not re-read dcv.conf. There appears to be no CLI command, signal, or admin action that forces a live virtual-session agent to reload config or drop its audio connection. dcv reload-licenses is the only reload-type command, and it does not apply here.

Because our users keep virtual sessions open for months, natural turnover does not retire the vulnerable pre-change sessions on any useful timescale, and the only supported remediation we can find is dcv close-session followed by recreation, which is disruptive to the user.

Requests:

  • Is there any supported mechanism in 2025.0 to disable audio (or otherwise drop the PulseAudio connection) on an already-running virtual session without closing and recreating it?
  • Does restarting the dcvserver service force running virtual-session agents to re-read config, and what exactly happens to active Linux virtual sessions (Xdcv display, desktop, user applications) when the service restarts? The "Stopping the Amazon DCV Server" documentation states stopping the server terminates all active sessions but does not describe the Linux virtual-session process-tree behavior specifically.

Questions for AWS

  1. Is the dcvagent PulseAudio-teardown SIGSEGV (backtrace above) a known issue, and is a fix planned or present in a specific 2025.0 build?
  2. Is [audio] enabled=false the supported and documented way to disable audio on Linux virtual sessions? If not, what is?
  3. Is there any supported way to apply the audio setting to a running session without recreating it?
  4. What is the documented behavior of systemctl restart dcvserver for active Linux virtual sessions?

What would resolve this for us

Either a patched build that fixes the teardown crash with audio enabled, or official documentation of a supported audio-disable key plus a supported way to apply it to running sessions. Until then we are disabling audio fleet-wide for all new sessions and coordinating recreation of the long-lived pre-change sessions.

  • Florian Turnwald EXPERT
    a month ago

    If my answer was helpful, I would appreciate it if you could mark it as the accepted answer.

Topics
Compute
Tags
NICE DCV
Language
English

asked a month ago90 views

3 Answers
2

Regarding [audio] enabled=false

The [audio] section follows the standard boolean configuration pattern used across DCV configuration blocks. While not explicitly listed in the current parameter reference, setting enabled=false prevents the dcvagent from initializing the PulseAudio connection during session startup, effectively bypassing the problematic teardown path.

Regarding application to running sessions

Parameters within the [audio] block are session-context settings, loaded only upon session creation. There is no supported CLI mechanism, signal, or administrative command to force a live dcvagent to reload configuration or dynamically release the PulseAudio/dbus connection without terminating the session.

Regarding systemctl restart dcvserver

Restarting the dcvserver service terminates all active virtual sessions. The DCV server manages the lifecycle of the Xdcv process and the associated dcvagent. A service restart triggers a termination signal to these child processes, resulting in the immediate loss of the session, desktop environment, and all running applications.

Regarding the SIGSEGV

The provided backtrace indicates a use-after-free or race condition within the libpulse / dbus / glib teardown sequence in libdcv.so. This indicates a defect within the library itself. Opening an AWS Support case is necessary to report the issue and track the requirement for a fix in a future 2025.0.x release.

EXPERT

answered a month ago

0

Based on the available documentation, I can address some of your questions, though I cannot confirm details about the specific crash you're experiencing or undocumented parameters.

Regarding the [audio] enabled parameter: The documented audio parameters in the [audio] section are avsync-support and source-channels. The enabled parameter you've discovered is not listed in the official parameter reference. Without official documentation, I cannot confirm whether [audio] enabled=false is a supported configuration option or guarantee its behavior across versions.

Regarding session-context parameters: You are correct that [audio] section parameters have a "session" reload context, meaning they are loaded when a session is created. Changes to these parameters apply to newly created sessions, not existing ones. This is the documented behavior for session-context parameters.

Regarding virtual session behavior: When investigating virtual session issues on Linux, the relevant logs are typically found in /var/log/dcv/sessionlauncher.log and /var/log/dcv/dcv-session.user.session.log. System logs like dmesg and journalctl -xe can provide additional details about failing components.

Virtual sessions on Linux are created with the dcv create-session command. Sessions can terminate unexpectedly if applications launched by the init script crash or if required tools are missing, even if the initial creation appears successful.

What I recommend: Given that you're experiencing a crash with a specific build and have found a workaround using an undocumented parameter, I strongly recommend opening a support case through the AWS Support Center (https://console.aws.amazon.com/support/) to:

  1. Report the SIGSEGV crash with your detailed backtrace
  2. Request official confirmation on the supported method to disable audio on Linux virtual sessions
  3. Inquire about any known issues with PulseAudio teardown in your specific build
  4. Ask about supported methods for applying configuration changes to running sessions

Your detailed analysis and backtrace will be valuable for the support team to investigate this issue properly.
Sources
Amazon DCV Server parameter reference - Amazon DCV
Investigating Virtual Session Creation Failure on Linux - NICE DCV

answered a month ago

EXPERT

reviewed a month ago

0

Hello.

I checked the documentation as well, and according to the publicly available Amazon DCV parameter reference, only avsync-support and source-channels are explicitly described in the audio section; enabled is not listed.
Since AWS rarely discloses its future roadmap, it is difficult to determine whether compatibility is officially guaranteed until the information is released as an update.
https://docs.aws.amazon.com/dcv/latest/adminguide/config-param-ref.html

The documentation does not appear to list a CLI command to force a running dcvagent to reload arbitrary dcv.conf settings, nor does it mention any administrative operation to disconnect and reinitialize only the PulseAudio connection.
Therefore, if the audio settings are designed to be loaded as part of the session context at the time of session creation, it is highly likely that—as a general rule—you would need to terminate and recreate the session to apply changes to an existing long-running session.

EXPERT

answered a month ago

EXPERT

reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content