Simple MPD client receiving SIGPIPE to my surprise

[wlhlm]

I've written a small status program that displays the currently loaded song in MPD in my i3 status bar. The code can be found here.

The program uses libmpdclient and basically works like this:

#include <mpd/client.h>

int main (...) {
    struct mpd_connection *connection = mpd_connection_new("/path/to/mpd/unix.socket", 0, 0);

    // loop every 5 seconds
    for (;;) {
        // get current track progress
        struct mpd_status *status;
        status = mpd_run_status(connection);
        total = mpd_status_get_total_time(status);

        // get current track info
        struct mpd_song *song;
        song = mpd_run_current_song(connection);
    }
}

So it connects to MPD over a UNIX domain socket once on startup and than requests the status and current song every 5 seconds reusing the same connection that was initially setup.

My problem is that at some point the connection to MPD breaks causing the process to receive a SIGPIPE. Reading the manpages, this signal occurs when my program tries to write to the UNIX domain socket (for example requesting the current song progress), but there is no one on the other side reading from the socket. This is a bit surprising to me since at no point MPD is stopped or restarted, so why would it stop reading from the socket? If I restart my program, it can communicate again with MPD (for some time until the problem appears again).

I'm not too familiar with how UNIX domain sockets work under the hood.

To investigate this issue, I enabled logging. Here you can see an instance of my program receiving a SIGPIPE:

[...]
Apr 22 21:08 : client: [0] process command "status"
Apr 22 21:08 : client: [0] command returned 0
Apr 22 21:08 : client: [0] process command "currentsong"
Apr 22 21:08 : client: [0] command returned 0
Apr 22 21:08 : client: [0] process command "status"
Apr 22 21:08 : client: [0] command returned 0
Apr 22 21:08 : client: [0] process command "currentsong"
Apr 22 21:08 : client: [0] command returned 0
Apr 23 13:33 : client: [0] timeout
Apr 23 13:33 : client: [0] closed

This is with log_level "verbose". What happened here is that I put my computer into hibernation (as I always do) and then upon resume my client received SIGPIPE (MPD logs a timeout here). The thing is, this does not happen on every resume from hibernate, only occasionally for some reason.

Is it expected that an MPD client might receive a SIGPIPE when connecting to MPD using a UNIX domain socket even while MPD is continuously running without getting stopped or restarted? If so, what would be a good strategy to implement here to deal with this situation? Connect once to MPD on startup and then keep checking after each command sent to MPD if we received a SIGPIPE and than reconnect, or just bluntly reconnect to MPD every time we have to run the status commands and then close the connection again every 5 seconds?

This is on Arch Linux, mpd 0.23.12-3 (though this has been an issue for many years), and MPD is started from the systemd-user service that comes with the package.

[MaxKellermann]

https://www.musicpd.org/help/

[wlhlm]

Apologies, if I was missing crucial information in my help request. I hope the following clears it up:

• output of mpd --version, libmpdclient 2.20, but again this has been happening for years across multiple client and daemon versions
• mpd.conf
• relevant portions of the log file (--verbose) are already included above (please let me know if more parts of the log are needed)
• I hope I made it clear above what I expect MPD to do and what actually happens

In addition, I have gone over the manuals again and searched on Github, and was unable to find anything relating to my issue.

[MaxKellermann]

The problem is indeed the regular connection timeout. If you suspend your computer, all the time has passed is counted for the timeout - indeed, MPD hasn't received any input for that amount of time! That's how MPD's timeout works.

The easierst way to avoid this problem is to not poll manually, but instead listen for idle events, and only query MPD if something has really changed. Side effect: this reduces CPU wakeups to a minimum and thus saves CPU time and electricity.

[wlhlm]

Thank you for taking a look at this!

The problem is indeed the regular connection timeout. If you suspend your computer, all the time has passed is counted for the timeout - indeed, MPD hasn't received any input for that amount of time! That's how MPD's timeout works.

That doesn't quite reflect my experience. Your explanation makes it sound like this timeout will be triggered pretty much every time the OS is suspended for more than a few minutes. However, this happens pretty rarely for me, I'd say about once out of every ~10 resumes spanning hours, days up to a week. Here is an example from today:

[...]
Apr 24 11:04 : client: [0] process command "currentsong"
Apr 24 11:04 : client: [0] command returned 0
Apr 24 11:04 : client: [0] process command "status"
Apr 24 11:04 : client: [0] command returned 0
Apr 24 11:04 : client: [0] process command "currentsong"
Apr 24 11:04 : client: [0] command returned 0
Apr 24 12:47 : client: [0] process command "status"
Apr 24 12:47 : client: [0] command returned 0
Apr 24 12:47 : client: [0] process command "currentsong"
Apr 24 12:47 : client: [0] command returned 0
Apr 24 12:47 : client: [0] process command "status"
Apr 24 12:47 : client: [0] command returned 0
[...]

I resumed the computer after more than an hour, and everything continued working fine. My config uses the default client timeout of 60 seconds, so that should have triggered it upon resume.

The easierst way to avoid this problem is to not poll manually, but instead listen for idle events, and only query MPD if something has really changed. Side effect: this reduces CPU wakeups to a minimum and thus saves CPU time and electricity.

Appreciate the recommendation. From what I can gather, that doesn't quite work for polling the song playback progress via status. I can imagine using idle events for efficiency while playback is paused and switch to polling once a song is playing (and from a cursory glance, it looks like this is what ncmpcpp does as well), but in that case the client is still as vulnerable to receiving SIGPIPE as it is currently, so I still need special handling for that.

[MaxKellermann]

Your explanation makes it sound like this timeout will be triggered pretty much every time the OS is suspended for more than a few minutes. However, this happens pretty rarely for me

Then that's a MPD bug.

still as vulnerable to receiving SIGPIPE as it is currently

No matter what MPD does, this indicates a bug in your client that you should fix. Your client should be able to handle disconnects gracefully. You appear to be new to coding if you didn't know about SIGPIPE, but it's easy to disable it (signal(SIGPIPE, SIG_IGN)) and handle the socket send error by reconnecting.

[wlhlm]

Then that's a MPD bug.

OK, but why would the passing of walltime during suspend matter here for the client timeout? Specifically for local connections such as a localhost or UNIX domain socket where both the server and client are suspended/resumed simultaneously. At least to me, it sounds like you should be able to just resume, ignoring the time gap.

Though If you really think that's not desired, I can open up a bug report.

No matter what MPD does, this indicates a bug in your client that you should fix. Your client should be able to handle disconnects gracefully.

You're right. I certainly have to improve that.

For this status program, I'd trade maximum efficiency for implementation simplicity. That's why I was asking for recommendations. Implementing the idle on pause/poll on playback approach I mentioned above will require a bunch of extra code to integrate into the poll(3)-based main loop of my program. Another alternative I saw in a different client is to just run the ping command before every refresh interval and try reconnect if that fails. Pretty simple to implement. (EDIT: It appears the ping command is not available through libmpdclient)

You appear to be new to coding if you didn't know about SIGPIPE, but it's easy to disable it (signal(SIGPIPE, SIG_IGN)) and handle the socket send error by reconnecting.

I can guess you can say that I'm pretty new, certainly when I first wrote the status program, however it actually had SIGPIPE handling you mention since pretty early on. I guess the reason I'm focusing on the SIGPIPE aspect in this discussion here was that I couldn't figure out why MPD would stop listening on the socket even though it was never stopped or restarted.

Again, thanks for the advice. Much appreciated.