[Problem]: emergency exit hangs

[timg7]

What happened?

I am running shairport-sync with a USB audio device via Alsa, and it is working perfectly - except if the audio device disappears unexpectedly.

Shairport detects and reports the disconnection event correctly and announces that it is going to exit, but then hangs and needs a kill -9.

I'm not sure how to investigate this further. Any advice welcome.

Relevant log output

fatal error: An unrecoverable error, "output_device_error_19", has been detected. Doing an emergency exit, as no run_this_if_an_unfixable_error_is_detected program.

System Information.

Running latest shairport-sync on a Raspberry Pi 3 with up-to-date Trixie (no GUI/desktop), compiled as per instructions on this github.

Configuration Information.

$ shairport-sync --displayConfig
>> Display Config Start.

From "uname -a":
 Linux mtunes 6.18.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64 GNU/Linux

From /etc/os-release:
 Debian GNU/Linux 13 (trixie)

From /sys/firmware/devicetree/base/model:
 Raspberry Pi 3 Model B Plus Rev 1.3

Shairport Sync Version String:
 5.1-AirPlay2-smi10-OpenSSL-Avahi-ALSA-soxr-sysconfdir:/etc

Command Line:
 shairport-sync --displayConfig

Configuration File:
 /etc/shairport-sync.conf

Configuration File Settings:
 general : 
 {
   name = "mTunes";
   volume_range_db = 60;
 };

>> Display Config End.
>> Goodbye!

PulseAudio or PipeWire installed?

• Check if your system uses a Sound Server.

How did you install Shairport Sync?

Built from source

Check previous issues

• Confirm

[mikebrady]

Thanks for the report -- we'll check it out, see if it can be reproduced.

[timg7]

As far as I can see the hang is happening after the call to exit() at the end of _die() in utilities/debug.c.

[mikebrady]

Thanks. There is a bug here alright. The system is trying to quit the application as cleanly as possible and is being caught waiting for something -- possibly a pthread mutex to be unlocked.

[mikebrady]

I think this is now fixed in the development branch. If you got a chance to check it out, it would be appreciated.

[mikebrady]

Actually, a slightly different fix was also pushed. Build 5.2-dev-33-g2ba3b116.

[timg7]

Hi Mike, Gosh, that was quick. I tested the development branch at commits 2ba3b11 and 68a78e8 (see below). Both snapshots show the same behaviour, and indeed it no longer hangs upon disconnecting the audio device. Is the segmentation fault expected? I also tested the effect of disconnecting the audio device with a few other audio players, but didn't learn much: no messages and no hangs.

BTW, many thanks for all the work you do on shairpoint-sync. -Tim

$ wget https://github.com/mikebrady/shairport-sync/archive/2ba3b1163a1383c067592b89d25cf974cbf5b317.zip
$ unzip 2ba3b1163a1383c067592b89d25cf974cbf5b317.zip
$ cd shairport-sync-2ba3b1163a1383c067592b89d25cf974cbf5b317/
$ autoreconf -fi
$ ./configure --sysconfdir=/etc --with-alsa     --with-soxr --with-avahi --with-ssl=openssl --with-systemd-startup --with-airplay-2
$ make
$ ./shairport-sync 
Can not set realtime properties of thread "alsa_buf_mon".
[start streaming audio, then disconnect USB bus]
Segmentation fault

# repeat for 68a78e82f32f71e87cb9b8c6ef27822dac43b760.zip

[mikebrady]

Thanks for the response. The segmentation error is definitely not part of the plan 🙂.

This is what I get:

mike@Debian13X:~/shairport-sync-github$ ./shairport-sync
Can not set realtime properties of thread "alsa_buf_mon".
fatal error: An unrecoverable error, "output_device_error_19", has been detected. Doing an emergency exit, as no run_this_if_an_unfixable_error_is_detected program.
mike@Debian13X:~/shairport-sync-github$ 

In your case, apart from the segmentation fault, the message isn't even getting out.

So, I've added a time delay to the die() function so that it waits two seconds before exiting. Hopefully this will give your system time to get that message out. That modification has been pushed onto the development branch.

TBH, this is all a bit crude, IMHO, so we will experiment with something more refined.

Now, regarding the different versions -- you seem to be using wget to download the source, but it would be much better to use git, as shown in the guide. There is a brief justification (for another program) here.

But there is more: when you need to update because a new update has been pushed to the GitHub repository, you don't need to re-download everything, you just go into the your directory containing the local repository and do a $ git pull, something like this:

$ cd shairport-sync
$ git pull
...continue

[timg7]

A little more info on the segfault. It is triggered when run_this_if_an_unfixable_error_is_detected executes a command that then fails. For example:

sessioncontrol = {
  run_this_if_an_unfixable_error_is_detected = "ls /banana";
};

For context: I was running shairport-sync as a systemd service and using run_this_if_an_unfixable_error_is_detected as a fail-safe mechanism to inform systemd when it should expect the service to quit. systemd will monitor processes which it is expecting to quit, and automatically kill them if they hang. During my testing I was running shairport directly from the command line, so the systemd notification mechanism failed.

[mikebrady]

Thanks for that.

The clean program termination mechanism -- tidying up before terminating the program -- is an older part of Shairport Sync and, upon closer examination, is in need of fixing / updating (even the code to handle a SIGINT or SIGTERM is technically unsound).

So let us take a short while to revise it and make it compliant with Unix guidelines. It might take a few days...