Linux failed to connect to socket

Can not connect to Linux «abstract» unix socket

I’m trying to use UNIX sockets for inter-thread communication. The program is only intended to run on Linux. To avoid creating the socket files, I wanted to use «abstract» sockets, as documented in unix(7). However, I don’t seem to be able to connect to these sockets. Everything works if I’m using «pathname» sockets, though. Here is the code (I haven’t quoted any error handling, but it’s done): thread#1:

int log_socket = socket(AF_LOCAL, SOCK_STREAM, 0); struct sockaddr_un logaddr; socklen_t sun_len = sizeof(struct sockaddr_un); logaddr.sun_family = AF_UNIX; logaddr.sun_path[0] = 0; strcpy(logaddr.sun_path+1, "futurama"); bind(log_socket, &logaddr, sun_len); listen(log_socket, 5); accept(log_socket, &logaddr, &sun_len); . // send - receive 

struct sockaddr_un tolog; int sock = socket(AF_LOCAL, SOCK_STREAM, 0); tolog.sun_family = AF_UNIX; tolog.sun_path[0] = 0; strcpy(tolog.sun_path+1, "futurama"); connect(sock, (struct sockaddr*)&tolog, sizeof(struct sockaddr_un)); 

If all I do in the above code, is change the sun_path to not have leading \0, things work perfect. strace output:

t1: socket(PF_FILE, SOCK_STREAM, 0) = 0 t1: bind(0, , 110) t1: listen(0, 5) t2: socket(PF_FILE, SOCK_STREAM, 0) = 1 t2: connect(1, , 110 t2: ) = -1 ECONNREFUSED (Connection refused) t1: accept(0,

I know that the connect comes before accept, that’s not an issue (I tried making sure that accept() is called before connect(), same result. Also, things are fine if the socket is «pathname» anyway).

For communication between threads of the same process, an ordinary pipe(2) should be enough! And you could also use pipes if all the communicating processes and/or threads have the same parent process!

@BasileStarynkevitch pipe will not work in my case. I need multiple threads to send info, and receive a synchronous response before moving on.

@BasileStarynkevitch for this, I will have to know in advance how many maximum pipes to open, or limit access to one using locks. The socket approach has less overhead for such case.

4 Answers 4

While I was posting this question, and re-reading unix(7) man page, this wording caught my attention:

an abstract socket address is distinguished by the fact that sun_path[0] is a null byte (’\0’). All of the remaining bytes in sun_path define the «name» of the socket

So, if I bzero’ed the sun_path before filling in my name into it, things started to work. I figured that’s not necessarily straight-forward. Additionally, as rightfully pointed out by @davmac and @StoneThrow, the number of those «remaining bytes» can be reduced by specifying only enough length of the socket address structure to cover the bytes you want to consider as your address. One way to do that is to use SUN_LEN macro, however, the first byte of the sun_path will have to be set to !0, as SUN_LEN uses strlen .

If sun_path[0] is \0, The kernel uses the entirety of the remainder of sun_path as the name of the socket, whether it’s \0-terminated or not, so all of that remainder counts. In my original code I would zero the first byte, and then strcpy() the socket name into the sun_path at position 1. Whatever gibberish that was in sun_path when the structure was allocated (especially likely to contain gibberish since it’s allocated on the stack), and was included in the length of the socket structure (as passed to the syscalls), counted as the name of the socket, and was different in bind() and connect().

IMHO, strace should fix the way it displays abstract socket names, and display all the sun_path bytes from 1 to whatever the structure length that was supplied, if sun_path[0] is 0

Источник

Arch Linux

OK, I use testing, and most of the time it’s fine. However, tonight I fired up an, at the «desktop», nada. Switch between TTY1 and TTY7 (TTY7 is my xserver) and I have an X error «Unable to connect to server».

After some playing, going back to Dbus from core got me going. DBus from Testing is kiss of death. A quick search shows nothing. Is this a known problem, or should I be reporting a bug?

Last edited by jasonwryan (2016-09-01 19:01:49)

Ryzen 5900X 12 core/24 thread — 2 x GTX 1070 8Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

#2 2016-08-16 23:02:25

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Registered Linux User #482438

#3 2016-08-24 11:37:08

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Nope, I still have the same problem even after dbus 1.10.10-3. More info.

dbus 1.10.10 removes libdbus, presumably providing it itself now, instead of it being split. Last version of libdbus seems to be 1.10.8

The error provided by my (very limited — no window borders, can’t alt-tab etc. No wallpaper) xfce session is

Failed to connect to socket /tmp/dbus-xxxxxxxxx: Connection refused

The last message on TTY1 (I run X on TTY7) is

a start job is running for user manager for uid 1000

Which has gone to 1min 30 secs and just stops there.

I can get to a fully working desktop again by killing lightdm, which forces a re-login. However, the blinking light on my webcam suggests something is still awry (possibly connected to pulseaudio)

downgrading dbus to 1.10.8-3 and reinstalling libdbus 1.10.8-3 gets things back to normal. For now, I have them added to ignore in pacman.conf.

The only other ignored package is ttf-ms-win10 until I have time to extract and sha256sum the fonts, but since this is an AUR package it shouldn’t have any bearing. Everything else is up to date (xorg, xfce4, lightdm) and as far as I know they haven’t been updated recently. I can’t find anything on the wiki, unless I’m searching for the wrong thing.

Last edited by Roken (2016-08-24 11:38:43)

Ryzen 5900X 12 core/24 thread — 2 x GTX 1070 8Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

#4 2016-08-28 10:02:58

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Looking at the changelog, the Arch package removed X11 support with the 1.10.10 update. You should probably open a bug on flyspray about this.

Last edited by Alad (2016-08-28 10:06:43)

Mods are just community members who have the occasionally necessary option to move threads around and edit posts. — Trilby

#5 2016-08-28 10:38:01

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Good call. I added it to bugzilla upstream. Reported on flyspray, too.

Ryzen 5900X 12 core/24 thread — 2 x GTX 1070 8Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

#6 2016-08-28 15:52:57

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

You seem to be the only one with this issue, though. dbus should be launched in the systemd user session, not through dbus-launch. Do you have the unit masked or something? Session broken?

#7 2016-08-28 19:20:35

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

I have never masked dbus, and never had a problem with it. The problem could be so many things, tho’. Lightdm, pam, dbus etc. etc. Really hoping someone else gets the problem so that I can start narrowing it down.

Ryzen 5900X 12 core/24 thread — 2 x GTX 1070 8Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

#8 2016-08-29 09:26:16

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Had exactly the same problem and solved it by replacing systemd-user and login in /etc/pam.d with their newer versions (.pacnew)

#9 2016-08-29 14:42:05

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

. dbus should be launched in the systemd user session, not through dbus-launch.

Well I don’t know how I missed the news on this but I did! This is why Xorg was freezing for me. I’ve altered my startup appropriately and all working now. Thanks for the pointer.

Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64

#10 2016-08-30 06:09:28

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Had exactly the same problem and solved it by replacing systemd-user and login in /etc/pam.d with their newer versions (.pacnew)

HTH

Thank you — I had a similar problem and this fixed it for me.

#11 2016-08-30 08:44:39

Re: Failed to connect to socket /tmp/dbus-xxx: Connection refused

Had exactly the same problem and solved it by replacing systemd-user and login in /etc/pam.d with their newer versions (.pacnew)

HTH

Thank you — I had a similar problem and this fixed it for me.

There are no .pacnew files in /etc/pam.d on my system

( Not using the testing repo’s )

auth required pam_securetty.so
auth requisite pam_nologin.so
auth include system-local-login
account include system-local-login
session include system-local-login

Current systemd-user contains:

# This file is part of systemd.
#
# Used by systemd —user instances.

account include system-login

session required pam_loginuid.so
session include system-login

syndaemon: no process found
/etc/mdm/Xsession: Beginning session setup.
dbus-update-activation-environment: error: unable to connect to D-Bus: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead
/etc/mdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent — startxfce4
/usr/bin/startxfce4: X server already running on display :0
xrdb: «Xft.hinting» on line 14 overrides entry on line 6
xrdb: «Xft.hintstyle» on line 17 overrides entry on line 7

(xfce4-session:557): xfce4-session-CRITICAL **: Unable to contact D-Bus session bus: Failed to connect to socket /tmp/dbus-lnsiT0sgGL: Connection refused

Last edited by ppine (2016-08-30 09:35:09)

Источник

connection error in unix domain socket implemented in c (gcc) centos 7

I have checked the path «/tmp/dsock» and the socket file «dsock» is there but looking inside the file shows:

 File: ‘dsock’ Size: 0 Blocks: 0 IO Block: 4096 socket Device: 801h/2049d Inode: 1572866 Links: 1 Access: (0777/srwxrwxrwx) Uid: ( 7418/user) Gid: (25/group) Access: 2017-08-31 17:16:29.569038461 -0600 Modify: 2017-08-31 17:16:29.569038461 -0600 Change: 2017-09-01 13:28:07.162071494 -0600 Birth: - 

Can’t find what the error is. The client side also shows similar connection error. Is it due to the UNIX domain socket file permission issues?

The first step in tackling these kind of problems is ALWAYS to see the error that the system returned. Most UNIX system calls will set errno to give specific error details when they return -1 on error. You should: 1) Include errno.h 2) Log detailed error messages using: printf(«Error %d: %s\n», errno, strerror(errno)); This should ideally be done as part of the routine system call error check

2 Answers 2

You cannot call connect on a listening socket. Once you have bound and listened, the only thing you should do with a listening socket is call accept (or close or use its descriptor in a select ).

So the server should create the socket, bind its address, listen on it and then the server should be sitting («blocked») in the accept function. That is, it’s waiting for a connection, usually in a loop.

Then (after the server has been started and is waiting) your client needs to create its own socket and call connect on it — specifying the same address that the server used when it called bind . This will cause the accept call in the server to return a new socket descriptor for a socket that is actually connected to the client. This is the one that you will use send and recv on for communication. (And the client’s socket will also be connected.)

At this point, the listening socket in the server will still be available to accept additional connections (each of which would return its own new unique socket descriptor).

Although possible, it doesn’t really make sense for the server to connect to its own listening socket endpoint anyway. What would be the point?

Источник