| Summary: | "Daemon startup failed" due to "Failed to remove stale UNIX socket" and NFS-mounted homes | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Peter Schwenk <schwenk> |
| Component: | daemon | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
| Severity: | critical | ||
| Priority: | medium | CC: | colin, lennart |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | triaged | ||
| i915 platform: | i915 features: | ||
| Attachments: | Attempt to make runtime paths smaller | ||
|
Description
Peter Schwenk
2012-01-11 07:28:38 UTC
It looks like we're not allowing enough space in a variable somewhere for the full socket path name.
Looking at the code, we're mostly pretty careful about our paths and using flexible allocation etc., however I do notice this:
pa_socket_server* pa_socket_server_new_unix(pa_mainloop_api *m, const char *filename) {
int fd = -1;
struct sockaddr_un sa;
pa_socket_server *s;
pa_assert(m);
pa_assert(filename);
if ((fd = pa_socket_cloexec(PF_UNIX, SOCK_STREAM, 0)) < 0) {
pa_log("socket(): %s", pa_cstrerror(errno));
goto fail;
}
memset(&sa, 0, sizeof(sa));
sa.sun_family = AF_UNIX;
pa_strlcpy(sa.sun_path, filename, sizeof(sa.sun_path));
Here, it's a limitation of the sa.sun_path.
Looking further in /usr/include/sys/un.h:
struct sockaddr_un
{
__SOCKADDR_COMMON (sun_);
char sun_path[108]; /* Path name. */
};
So there we have it. 108 characters.
Not quite sure how to address this. I guess we could pass the path through realpath() first to reduce the file size down, but it's certainly not a universal solution. We should probably fail more gracelessly(!) when the path overflows.
Created attachment 58413 [details] [review] Attempt to make runtime paths smaller This patch might solve the problem in your case. Longer term, we'll be wanting to switch to a folder inside /run/user/$USER/ which we can guarantee no other user can write to (which is why we do the whole crazy symlinking stuff). Ultimately the /run/user/$USER/ dir is supplied to us in XDG_RUNTIME_DIR variable under modern systems. However, in the mean time, please can you try this patch and let me know? OK, I've tested and committed a similar patch to the one posted here. It should work around the issues for now, but a "full and proper" fix is to use XDG_RUNTIME_DIR which we will support in the fullness of time. Cheers Thanks. I was unable to test the patch, but it seems very reasonable. On Mar 28, 2012, at 7:17 AM, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=44680 > > Colin Guthrie <fdo@colin.guthr.ie> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |FIXED > > --- Comment #3 from Colin Guthrie <fdo@colin.guthr.ie> 2012-03-28 04:17:38 PDT --- > OK, I've tested and committed a similar patch to the one posted here. > > It should work around the issues for now, but a "full and proper" fix is to use > XDG_RUNTIME_DIR which we will support in the fullness of time. > > Cheers > > -- > Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. -- Peter Schwenk || Campus IT Associate 3 Mathematical Sciences || University of Delaware Newark, DE 19716-2553 || (302) 831-0437 (v) schwenk @ math . udel . edu || http://www.math.udel.edu/~schwenk |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.