How to correctly use PF_UNIX, SOCK_DGRAM sockets? - Unix

This is a discussion on How to correctly use PF_UNIX, SOCK_DGRAM sockets? - Unix ; Hello. I have a socket in the filesystem created using socket() and bind() with PF_UNIX and SOCK_DGRAM. The process that created it has exited, the socket has effectively been sitting there with no reader or writer for an indeterminate amount ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

  1. How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    Hello.

    I have a socket in the filesystem created using socket() and bind()
    with PF_UNIX
    and SOCK_DGRAM.

    The process that created it has exited, the socket has effectively
    been sitting there
    with no reader or writer for an indeterminate amount of time.

    I create a new process, which blocks on a read() call on the socket.

    I then create another process that calls socket(), puts the name of
    the socket
    into a sockaddr_un and then calls sendto(), sending a string of bytes.

    The problem: sendto() always returns -1 (ECONNREFUSED).

    Have I missed something fundamental, dealing with these sockets? I'm
    effectively trying to get them to act like named pipes in the
    filesystem,
    only bidirectional. I'm writing a small open(), read() and write()
    style
    interface over the top so that client code doesn't have to deal with
    the
    sockets API directly.

    I'll post code if necessary (there isn't really any more than the
    description
    above).

    Any help would be appreciated.
    MC

  2. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Jun 3, 5:37 pm, artifact....@googlemail.com wrote:
    > Hello.
    >
    > I have a socket in the filesystem created using socket() and bind()
    > with PF_UNIX
    > and SOCK_DGRAM.
    >
    > The process that created it has exited, the socket has effectively
    > been sitting there
    > with no reader or writer for an indeterminate amount of time.
    >
    The socket's owner can't be exit. Actually it has to:

    1) socket()
    2) bind()
    3) read() or recvfrom()

  3. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Jun 3, 5:56 pm, Bin Chen wrote:
    > On Jun 3, 5:37 pm, artifact....@googlemail.com wrote:> Hello.
    >
    > > I have a socket in the filesystem created using socket() and bind()
    > > with PF_UNIX
    > > and SOCK_DGRAM.
    >
    > > The process that created it has exited, the socket has effectively
    > > been sitting there
    > > with no reader or writer for an indeterminate amount of time.
    >
    > The socket's owner can't be exit. Actually it has to:
    >
    > 1) socket()
    > 2) bind()
    > 3) read() or recvfrom()

    So, to clarify, a process can't re-use a socket that's just sitting
    in the filesystem? It must unlink() and re-create the socket?

    thanks,
    MC

  4. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    artifact.one@googlemail.com wrote:
    > On Jun 3, 5:56 pm, Bin Chen wrote:
    > > On Jun 3, 5:37 pm, artifact....@googlemail.com wrote:> Hello.
    > >
    > > > I have a socket in the filesystem created using socket() and bind()
    > > > with PF_UNIX
    > > > and SOCK_DGRAM.
    > >
    > > > The process that created it has exited, the socket has effectively
    > > > been sitting there
    > > > with no reader or writer for an indeterminate amount of time.
    > >
    > > The socket's owner can't be exit. Actually it has to:
    > >
    > > 1) socket()
    > > 2) bind()
    > > 3) read() or recvfrom()

    > So, to clarify, a process can't re-use a socket that's just sitting
    > in the filesystem? It must unlink() and re-create the socket?

    Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    but SysV systems obey permissions on the socket file, whilst BSD systems do
    not (give or take some exceptions). So, mind your umask.

    The Linux kernel has notion of an alternative namespace for domain sockets,
    accessible by specifying '\0' as the first character of a sun_path. This
    gives you all the semantics you probably expect. Alas, it's only for Linux,
    AFAIK.

    Now, just wait until you want to try accessing peer credentials...

  5. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Jun 3, 8:41 pm, William Ahern
    wrote:
    > artifact....@googlemail.com wrote:
    > > On Jun 3, 5:56 pm, Bin Chen wrote:
    > > > On Jun 3, 5:37 pm, artifact....@googlemail.com wrote:> Hello.
    >
    > > > > I have a socket in the filesystem created using socket() and bind()
    > > > > with PF_UNIX
    > > > > and SOCK_DGRAM.
    >
    > > > > The process that created it has exited, the socket has effectively
    > > > > been sitting there
    > > > > with no reader or writer for an indeterminate amount of time.
    >
    > > > The socket's owner can't be exit. Actually it has to:
    >
    > > > 1) socket()
    > > > 2) bind()
    > > > 3) read() or recvfrom()
    > > So, to clarify, a process can't re-use a socket that's just sitting
    > > in the filesystem? It must unlink() and re-create the socket?
    >
    > Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    > but SysV systems obey permissions on the socket file, whilst BSD systems do
    > not (give or take some exceptions). So, mind your umask.
    >
    > The Linux kernel has notion of an alternative namespace for domain sockets,
    > accessible by specifying '\0' as the first character of a sun_path. This
    > gives you all the semantics you probably expect. Alas, it's only for Linux,
    > AFAIK.
    >
    > Now, just wait until you want to try accessing peer credentials...

    Ugh. Thanks.
    MC

  6. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Jun 4, 3:41 am, William Ahern
    wrote:
    > artifact....@googlemail.com wrote:
    > > On Jun 3, 5:56 pm, Bin Chen wrote:
    > > > On Jun 3, 5:37 pm, artifact....@googlemail.com wrote:> Hello.
    >
    > > > > I have a socket in the filesystem created using socket() and bind()
    > > > > with PF_UNIX
    > > > > and SOCK_DGRAM.
    >
    > > > > The process that created it has exited, the socket has effectively
    > > > > been sitting there
    > > > > with no reader or writer for an indeterminate amount of time.
    >
    > > > The socket's owner can't be exit. Actually it has to:
    >
    > > > 1) socket()
    > > > 2) bind()
    > > > 3) read() or recvfrom()
    > > So, to clarify, a process can't re-use a socket that's just sitting
    > > in the filesystem? It must unlink() and re-create the socket?
    >
    > Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    > but SysV systems obey permissions on the socket file, whilst BSD systems do
    > not (give or take some exceptions). So, mind your umask.

    Which umask can do the job of unlink?


  7. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    William Ahern writes:

    >Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    >but SysV systems obey permissions on the socket file, whilst BSD systems do
    >not (give or take some exceptions). So, mind your umask.

    No, system V does not honor permissions (at least not on Solaris and
    its predecessors which I would maintain is as close to original SysV as
    you can get.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  8. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    Casper H.S. Dik wrote:
    > William Ahern writes:
    >
    > >Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    > >but SysV systems obey permissions on the socket file, whilst BSD systems do
    > >not (give or take some exceptions). So, mind your umask.
    >
    > No, system V does not honor permissions (at least not on Solaris and
    > its predecessors which I would maintain is as close to original SysV as
    > you can get.

    They are honored on AIX, at least according to IBM's manual.

    SunOS, Solaris' predecessor, was a BSD derivative. This is just speculation,
    but it would have made sense for them to persist the same behavior after
    they made the switch.

    In any event, some do, some don't, and there are sufficient numbers of both.

  9. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    Bin Chen wrote:
    > On Jun 4, 3:41 am, William Ahern
    > wrote:
    > > artifact....@googlemail.com wrote:

    > > > So, to clarify, a process can't re-use a socket that's just sitting
    > > > in the filesystem? It must unlink() and re-create the socket?
    > >
    > > Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    > > but SysV systems obey permissions on the socket file, whilst BSD systems do
    > > not (give or take some exceptions). So, mind your umask.
    >
    > Which umask can do the job of unlink?

    #define umask unlink

    =)

    The comment was apropos in the sense that the thread, fundamentally and
    critically, concerns the interplay between named domain sockets and the
    filesystem, and one's expectations of the behavior.

  10. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Jun 5, 6:12 am, William Ahern
    wrote:
    > Bin Chen wrote:
    > > On Jun 4, 3:41 am, William Ahern
    > > wrote:
    > > > artifact....@googlemail.com wrote:
    >
    > > > > So, to clarify, a process can't re-use a socket that's just sitting
    > > > > in the filesystem? It must unlink() and re-create the socket?
    >
    > > > Yes. As horrible as it sounds, it's stark reality. Not quite as bothersome,
    > > > but SysV systems obey permissions on the socket file, whilst BSD systems do
    > > > not (give or take some exceptions). So, mind your umask.
    >
    > > Which umask can do the job of unlink?
    >
    > #define umask unlink
    >
    > =)
    >
    > The comment was apropos in the sense that the thread, fundamentally and
    > critically, concerns the interplay between named domain sockets and the
    > filesystem, and one's expectations of the behavior.

    I can't get your meaning, obviously the parameter of these two
    functions are different.

    --
    I want to do language-exchange, I am seeking an English native speaker
    to talk with me about Linux, freedom software, UNIX programming etc.
    Skype: abai_1982

  11. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    "Bin Chen" schrieb im Newsbeitrag
    news:1180999322.576532.263130@o11g2000prd.googlegr oups.com...
    > On Jun 5, 6:12 am, William Ahern
    > wrote:
    >> Bin Chen wrote:
    >> > On Jun 4, 3:41 am, William Ahern
    >> > wrote:
    >> > > artifact....@googlemail.com wrote:
    >>
    >> > > > So, to clarify, a process can't re-use a socket that's just sitting
    >> > > > in the filesystem? It must unlink() and re-create the socket?
    >>
    >> > > Yes. As horrible as it sounds, it's stark reality. Not quite as
    >> > > bothersome,
    >> > > but SysV systems obey permissions on the socket file, whilst BSD
    >> > > systems do
    >> > > not (give or take some exceptions). So, mind your umask.
    >>
    >> > Which umask can do the job of unlink?
    >>
    >> #define umask unlink
    >>
    >> =)
    >>
    >> The comment was apropos in the sense that the thread, fundamentally and
    >> critically, concerns the interplay between named domain sockets and the
    >> filesystem, and one's expectations of the behavior.
    >
    > I can't get your meaning, obviously the parameter of these two
    > functions are different.
    of course they are. You have to use unlink() to remove the socket, umask()
    won't do it for you. The only thing umask() might do for unlink() is to
    allow for the unlink() to not fail with 'permission denied'

    bye, Jojo


  12. Re: How to correctly use PF_UNIX, SOCK_DGRAM sockets?

    On Sun, 03 Jun 2007 12:41:51 -0700, William Ahern wrote:

    > Yes. As horrible as it sounds, it's stark reality. Not quite as
    > bothersome, but SysV systems obey permissions on the socket file, whilst
    > BSD systems do not (give or take some exceptions). So, mind your umask.

    I don't think this is the whole story, AIUI setting umask() before you
    call listen() will affect the permissions needed to connect() to that
    socket, as will calling chmod() after you bind() however calling fchmod()
    at any point, may or may not affect anything (and mostly not).

    I'm pretty sure the umask() thing works on Linux and FreeBSD, and I
    assumed it did on Solaris. The chmod() thing is the "normal" way to do
    it, although I couldn't guarantee it works in more places ... fchmod()
    being the sane thing, but mostly unsupported.

    Can you see anything obviously wrong with the above?

    --
    James Antill -- james@and.org
    C String APIs use too much memory? ustr: length, ref count, size and
    read-only/fixed. Ave. 55% overhead over strdup(), for 0-20B strings
    http://www.and.org/ustr/
+ Reply to Thread
« Cannot use make to run programs | getting currently running processes in C »