2002-08-07 15:29:18

by Jan Hudec

[permalink] [raw]
Subject: UNIX domain socket hanging around when not closed

Hello,

I have a (possibly stupid) question. Is it OK, that dentries created by
binding unix-domain sockets remain in filesystem?

What I do is create a unix socket in /tmp and wait for clients to
connect in. The program removes the socket dentry when it shuts down,
but it sometimes crashes and the socket remains there.

Is there some reason the socket should remain unless explicitely
removed?

-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>


2002-08-07 15:55:01

by Alan

[permalink] [raw]
Subject: Re: UNIX domain socket hanging around when not closed

On Wed, 2002-08-07 at 16:32, Jan Hudec wrote:
> What I do is create a unix socket in /tmp and wait for clients to
> connect in. The program removes the socket dentry when it shuts down,
> but it sometimes crashes and the socket remains there.
>
> Is there some reason the socket should remain unless explicitely
> removed?

Thats what is supposed to happen. If its dead then in your server you
can remove it and create a new one.

2002-08-07 15:52:28

by Matti Aarnio

[permalink] [raw]
Subject: Re: UNIX domain socket hanging around when not closed

On Wed, Aug 07, 2002 at 05:32:51PM +0200, Jan Hudec wrote:
> Hello,
>
> I have a (possibly stupid) question. Is it OK, that dentries created by
> binding unix-domain sockets remain in filesystem?

That is the classical behaviour, possibly because of tradition
where they relate to named pipes created with mknod(1) command.

http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html

> What I do is create a unix socket in /tmp and wait for clients to
> connect in. The program removes the socket dentry when it shuts down,
> but it sometimes crashes and the socket remains there.
>
> Is there some reason the socket should remain unless explicitely
> removed?

Traditional is also to unlink() the socket name just prior
to bind(3):ing it just in case there is a left-over entity
with that name.


The object name (it is NAMED entity, after all) space is
filesystem name space. I don't see any reason why not:

- There could pre-exist the named socket (at a R/O
filesystem), and no new name needs to be allocated
in the filesystem for it.

- The entire named entity would not be allowed to
exist purely in VFS space, that is: creation wise
the permission verification could ignore location
directory being on a read/only file system, and
just use directory permissions. (Questions about
memory expenditure, etc. all kinds of trade-offs.)

What the new POSIX writes about the issue, that I haven't
yet looked into.

> Jan 'Bulb' Hudec <[email protected]>

/Matti Aarnio

2002-08-07 16:22:32

by Alan

[permalink] [raw]
Subject: Re: UNIX domain socket hanging around when not closed

On Wed, 2002-08-07 at 16:56, Matti Aarnio wrote:
> - There could pre-exist the named socket (at a R/O
> filesystem), and no new name needs to be allocated
> in the filesystem for it.
>
> - The entire named entity would not be allowed to
> exist purely in VFS space, that is: creation wise
> the permission verification could ignore location
> directory being on a read/only file system, and
> just use directory permissions. (Questions about
> memory expenditure, etc. all kinds of trade-offs.)

Linux has a non file system name space for AF_UNIX sockets too. But its
a Linux extension