search for: sockaddr_un

...users. No need to do an explicit memset if the compiler does it for us via an initializer. No need to use strncpy() which does wasted effort on short names, when we can use memcpy() given that we already checked length in order to detect truncation. Linux does not require a trailing NUL byte in sockaddr_un, so we can allow names one byte longer. Not entirely fixed: although the proposed NBD URI document mentions that URIs can start with a leading (encoded) NUL byte to access the Linux abstract socket namespace, our use of strlen(sun.sun_path) would truncate the trailing bytes - but to support abstra...

...names >= sizeof(sock.sun_path), and thus we are only ever copying in a name that will include a trailing NUL. However, note that Linux permits a socket name to use the full width of sun_path (for shorter names, you must either provide a trailing NUL or pass something smaller than sizeof(struct sockaddr_un) to connect(); but for the full-length name, a trailing NUL is not required). So, relax our off-by-one length restriction (we now permit the user to pass a 108-byte socket name, instead of a limit of 107), at which point the gcc complaint is no longer a false positive (we could indeed be copying a...

..." sock = socket(AF_UNIX, SOCK_STREAM, 0); 12 if (sock < 0) { 13 perror("opening stream socket"); 14 exit(1); 15 } 16 server.sun_family = AF_UNIX; 17 strcpy(server.sun_path, NAME); 18 if (bind(sock, (struct sockaddr *) &server, sizeof(struct sockaddr_un))) { 19 perror("binding stream socket"); 20 exit(1); 21 } I got ""binding stream socket Address already in use" when trying to bind the socket . But If I use such kind of thing : fd = open("/dev/virtio-ports/agent", O_RDWR | O_NONBL...

On Mon, 23 Feb 2015, Kevin Brott wrote: > > Yup - that cleared that hurdle ... now it dies here on AIX: > > xlc_r -O2 -qarch=ppc -qalloca -I/usr/include -I/opt/freeware/include > -I. -I. -O2 -qarch=ppc -qalloca -I/usr/include -I/opt/freeware/include > -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" >

...atible-pointer-types[https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wincompatible-pointer-types]] 369 | if (connect(fd, &addr, sizeof(addr)) != 0) { | ^~~~~ | | | struct sockaddr_un * In file included from ../includes.h:26, from port-linux.c:22: /usr/include/sys/socket.h:386:19: note: expected 'const struct sock...

...program I receive a warning in Dovecot log: 2011-09-29 14:45:30 doveadm(guest at testmail.com): Warning: Timeout leak: 0x7f14800ad970 This is the script: =============================== #!/usr/bin/perl use strict; use Socket; use IO::Handle; socket(TSOCK, PF_UNIX, SOCK_STREAM,0); connect(TSOCK, sockaddr_un("/var/run/dovecot/doveadm-server")) or print("ERROR!"); print "VERSION\tdoveadm-server\t1\t0\n"; print "\tguest\@testmail.com\tquota get\n"; print "=" x 20 . "\n"; if (defined(my $messg = <TSOCK>)) { print $messg; print...

...-09-26 13:58:14 Reading hosts file 2015-09-26 13:58:14 unix bind() failed: No such file or directory This message occurs in the Perl script /usr/share/BackupPC/bin/BackupPC : my $sockFile = "/var/run/BackupPC/BackupPC.sock"; unlink($sockFile); if ( !bind(SERVER_UNIX, sockaddr_un($sockFile)) ) { print(LOG $bpc->timeStamp, "unix bind() failed: $!\n"); exit(1); } As far as I can see (I'm no guru) this is trying to open a unix socket with the name /var/run/BackupPC/BackupPC.sock . There is no directory /var/run/BackupPC/ on m...

Including sys/un.h for sockaddr_un and sys/fcntl.h for O_CLOEXEC/O_NONBLOCK. --- src/launch-libvirt.c | 1 + src/launch-unix.c | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c index 1649884..ad07210 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -52,6 +52,7 @@...

...> -#include <errno.h> EINVAL is used here. > --- a/src/launch-direct.c > +++ b/src/launch-direct.c > @@ -31,8 +30,6 @@ > #include <sys/stat.h> > #include <signal.h> > #include <sys/socket.h> > -#include <sys/un.h> Isn't this needed by sockaddr_un? -- Pino Toscano

...the ncurses6-config tool. --- m4/guestfs_libraries.m4 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/m4/guestfs_libraries.m4 b/m4/guestfs_libraries.m4 index c5a4a01..e751db1 100644 --- a/m4/guestfs_libraries.m4 +++ b/m4/guestfs_libraries.m4 @@ -113,7 +113,14 @@ struct sockaddr_un myaddr; dnl tgetent, tputs and UP [sic] are all required. They come from the lower dnl tinfo library, but might be part of ncurses directly. PKG_CHECK_MODULES([LIBTINFO], [tinfo], [], [ - PKG_CHECK_MODULES([LIBTINFO], [ncurses]) + PKG_CHECK_MODULES([LIBTINFO], [ncurses], [], [ + AC...

...defined...not good with sockets without my bible in front of me, so can't play with this until at least Sunday :( The problem appears to be, in here, with the error generated by the 'fatal:' result when connect() is tested: char egd_message[2] = { 0x02, 0x00 }; struct sockaddr_un addr; int addr_len; memset(&addr, '\0', sizeof(addr)); addr.sun_family = AF_UNIX; /* FIXME: compile time check? */ if (sizeof(RANDOM_POOL) > sizeof(addr.sun_path)) fatal("Random pool path is too long"); strn...

...st obvious but I had not tried to trace it all the way back to the domain start job or checked the debug logs yet, sorry. So looking a bit more carefully I see the real issue is in src/qemu/qemu_monitor.c: 321 static int 322 qemuMonitorOpenUnix(const char *monitor, pid_t cpid) 323 { 324 struct sockaddr_un addr; 325 int monfd; 326 int timeout = 30; /* In seconds */ Is this safe to increase? Is there any reason to keep it at 30s given (from what I'm seeing on a fast 2-socket Haswell system) that hugepage backed guests larger than ~160GB memory will not be able to start in that time? --...

...: getnameinfo 1 failed: ai_family not supported > get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported That's strange, because we do: if (addr.ss_family == AF_UNIX) { /* Get the Unix domain socket path. */ return xstrdup(((struct sockaddr_un *)&addr)->sun_path); } so AF_UNIX should never get to getnameinfo...

...rfaces. >> >> > What address should look like if we will choose to use new address family? > An example will help me understand what problem you are trying to point out > easily. > One thing that's been discussed is to use something that looked much like struct sockaddr_un. As long as the strings were unique, they could be in whatever format people wanted. Of course, you should also take a look at VMware's VMCI. If we're going to have a socket interface, if we can have a compatible userspace interface, that would probably be a good thing. >>>...

...rfaces. >> >> > What address should look like if we will choose to use new address family? > An example will help me understand what problem you are trying to point out > easily. > One thing that's been discussed is to use something that looked much like struct sockaddr_un. As long as the strings were unique, they could be in whatever format people wanted. Of course, you should also take a look at VMware's VMCI. If we're going to have a socket interface, if we can have a compatible userspace interface, that would probably be a good thing. >>>...

...e can add more interop tests in future.) > > The upstream spec for systemd socket activation is here: > http://0pointer.de/blog/projects/socket-activation.html > --- > + > + /* Use /tmp instead of TMPDIR because we must ensure the path is > + * short enough to store in the sockaddr_un. On some platforms this > + * may cause problems so we may need to revisit it. XXX > + */ > + h->sa_tmpdir = strdup ("/tmp/libnbdXXXXXX"); > + h->sa_sockpath = strdup ("/tmp/libnbdXXXXXX/sock"); > + if (h->sa_tmpdir == NULL || h->sa_sockpath =...

On Wed, Feb 03, 2016 at 01:17:42PM +0100, Pino Toscano wrote: > Introduce a new read-only API to get a path where to store temporary > sockets: this is different from tmpdir, as we need short paths for > sockets (due to sockaddr_un::sun_path), and it is either > XDG_RUNTIME_DIR if set, or /tmp; adapt guestfs_int_create_socketname > to create sockets in that location. > > Furthermore, print sockdir and XDG_RUNTIME_DIR in test-tool for > debugging. As you saw, there were a few problems with this patch. However...

...ation.c +++ b/generator/states-connect-socket-activation.c @@ -94,22 +94,23 @@ prepare_socket_activation_environment (string_vector *env) string_vector_empty (env); return -1; } STATE_MACHINE { CONNECT_SA.START: enum state next; char *tmpdir; char *sockpath; int s; struct sockaddr_un addr; + struct execvpe execvpe_ctx; string_vector env; pid_t pid; assert (!h->sock); assert (h->argv.ptr); assert (h->argv.ptr[0]); next = %.DEAD; /* Use /tmp instead of TMPDIR because we must ensure the path is * short enough to store in the sockaddr_un. O...

...ain start job or checked the debug > > logs yet, sorry. So looking a bit more carefully I see the real issue > > is in src/qemu/qemu_monitor.c: > > > > 321 static int > > 322 qemuMonitorOpenUnix(const char *monitor, pid_t cpid) > > 323 { > > 324 struct sockaddr_un addr; > > 325 int monfd; > > 326 int timeout = 30; /* In seconds */ > > > > Is this safe to increase? Is there any reason to keep it at 30s given > > (from what I'm seeing on a fast 2-socket Haswell system) that hugepage > > backed guests larger than...

Hi, when running OpenSSH with EGD as entropy source, the sshd server connects to the EGD socket and leaves it open to re-seed on the fly. Unfortunately the connection is not checked when re-seeding, so that a failure or restart of EGD will lead to a "fatal()" abort of the sshd server process. Since a dying server process can not be accepted, I would recommend to not have sshd call it