[4.4.0] mpris-proxy service crashing and not restarting

I briefly tried to look out for the service, but couldn’t find it. Now that I did…

● mpris-proxy.service - Bluez5-MPRIS Proxy
Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; disabled; vendor preset: enabled)
Active: failed (Result: core-dump) since Sun 2022-01-02 19:28:03 EET; 2 days ago
Process: 6329 ExecStart=/usr/bin/mpris-proxy (code=dumped, signal=ABRT)
Main PID: 6329 (code=dumped, signal=ABRT)

Well thay explains it!

Restarting it worked, which is nice :slight_smile:

Perhaps stopping Android App Support crashes it…? That’s the only odd thing I did two days ago…

1 Like

I’ve pinged the author of BTons and added it to the update needed list, https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64

I fear it will only add to the confusion to resurrect it.

1 Like

Thanks! The author of BTons has alerted me to same :slight_smile: My itchy trigger finger … chop, chop.


Also, the service is marked as disabled… I guess some other process could start it, but I flipped it to enabled. Let’s see what happens in the next reboot :slight_smile:

Nope, it didn’t help. I still have to restart the service every almost daily.

There is an ugly workaround however; see this post

I’ve been checking to see to what extent this is hardware dependant and the service remains up and functional on the yolla/GS290 phones:

[defaultuser@VollaPhone ~]$ systemctl status --user mpris-proxy
● mpris-proxy.service - Bluez5-MPRIS Proxy
   Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2022-01-08 15:28:04 CET; 1 weeks 1 days ago
 Main PID: 1945 (mpris-proxy)
   CGroup: /user.slice/user-100000.slice/user@100000.service/mpris-proxy.service
           └─1945 /usr/bin/mpris-proxy
1 Like

I lost mpris-proxy again this weekend, and the reason is quite obvious:

$ systemctl --user status mpris-proxy
● mpris-proxy.service - Bluez5-MPRIS Proxy
   Loaded: loaded (/usr/lib/systemd/user/mpris-proxy.service; enabled; vendor preset: enabled)
   Active: failed (Result: core-dump) since Sat 2022-05-14 10:13:07 EEST; 2 days ago
  Process: 5934 ExecStart=/usr/bin/mpris-proxy (code=dumped, signal=SEGV)
 Main PID: 5934 (code=dumped, signal=SEGV)

Well, I think I figured out the obvious workaround: systemd --user edit mpris-proxy

Put the following lines in the editor:


After that the service restarted itself (after having segfaulted two days ago) as expected! Now, this causes the service to always restart, even in the case of OOM, but I think with its 0.1% memory usage it’s small enough to fly under the radar :slight_smile:


Is this also present on 4.4?

Yes; the last two posts were about a X10II tunning 4.4.0.

Can you update the first post with that information?

I can’t edit the post anymore, it’s too old…

And, sadly, this is still reproducible on X10III with the 6GB of RAM it has. Browser, Firefox, Deezer, Email, Whisperfish have been killed in action so far, and keeping an eye of htop suggests that OOM is the cause…

I try to fiddle with swappiness and friends, perhaps it just needs more aggreasive memory management.

1 Like

Thanks for the report @direc85, and for digging deeper into the reasons. I’ve amended your original report with the new info (new title, 10III, 4.4.0) for clarity.

I’ve also created an internal bug report, so this is now tagged as “tracked”.


Xperia 10 II with 4.4 installed from scratch doesn’t have this command.
@direc85 Do you know which package I need?

Whoops, that should be systemctl instead. Sorry about that!

1 Like

As a follow-up on this, the following change (following @direc85’s suggestion) has been made to prevent this from causing problems:

This will hopefully make it in to the next release, so I’ve tagged the topic as “fixed”.


The situation with this is worse with than before. I have lowered the oom memory limits as with the previous dot release, but it mpris_proxy.service still gets sniped. I manually edited the pull request in and it seems to work as expected. It’s only a mitigation, though…

Anyone else with the same experience with (w.r.t. specifically?

X10II (III is still sitting on shelf, waiting for 4.5)

Wow, so this was all along why my phone has been intermittently struggling to play A2DP audio on car head unit.

Fairly certain I’ve been struggling with this over a year now, ever since I swapped head units in my car (order date reads Oct '21), and got BT A2DP capability to it.

Fresh off Sailfish reboot, BT would connect and play A2DP music fine on Spotify.

It always felt like with all the OOMs Sailfish app suffers through a session, somehow phone’s Bluetooth capability deteriorated, but I could never figure out the details. Next ride, BT connects fine, but head unit audio player fails to play audio or display track info, and no on-screen controls work.

Turns out I was always looking in the wrong place, trying to journalctl through bluetooth unit.

Yep, systemctl --user status mpris-proxy had crashed with SIGABRT, just like [4.4.0] mpris-proxy service crashing and not restarting - #6 by direc85 shows.

Yep, systemctl --user restart mpris-proxy immediately restored all functionality (I also edited service unit for auto-restart), and ended this year-long frustration that made me want to test other head units and go through all that rebuild trouble.

Got a couple of long drives coming up, couldn’t be happier about getting ths figured out. You the man @direc85.

PS phone doesn’t seem to have coredumpctl so we can’t really get details on why mpris-proxy crashes?

PPS History for tools/mpris-proxy.c - bluez/bluez · GitHub for History, hopefully it becomes hardened upstream.