How to know whether any process is bound to a Unix domain socket?

前端 未结 2 1220
天命终不由人
天命终不由人 2021-02-01 02:11

I\'m writing a Unix domain socket server for Linux.

A peculiarity of Unix domain sockets I quickly found out is that, while creating a listening Unix socket creates the

相关标签:
2条回答
  • 2021-02-01 02:49

    I know I am very late to the party and that this was answered a long time ago but I just encountered this searching for something else and I have an alternate proposal.

    When you encounter the EADDRINUSE return from bind() you can enter an error checking routine that connects to the socket. If the connection succeeds, there is a running process that is at least alive enough to have done the accept(). This strikes me as being the simplest and most portable way of achieving what you want to achieve. It has drawbacks in that the server that created the UDS in the first place may actually still be running but "stuck" somehow and unable to do an accept(), so this solution certainly isn't fool-proof, but it is a step in the right direction I think.

    If the connect() fails then go ahead and unlink() the endpoint and try the bind() again.

    0 讨论(0)
  • 2021-02-01 03:02

    I don't think there is much to be done beyond things you have already considered. You seem to have researched it well.

    There are ways to determine if a socket is bound to a unix socket (obviously lsof and netstat do it) but they are complicated and system dependent enough that I question whether they are worth the effort to deal with the problems you raise.

    You are really raising two problems - dealing with name collisions with other applications and dealing with previous instances of your own app.

    By definition multiple instances of your pgm should not be trying to bind to the same path so that probably means you only want one instance to run at a time. If that's the case you can just use the standard pid filelock technique so two instances don't run simultaneously. You shouldn't be unlinking the existing socket or even running if you can't get the lock. This takes care of the server crash scenario as well. If you can get the lock then you know you can unlink the existing socket path before binding.

    There is not much you can do AFAIK to control other programs creating collisions. File permissions aren't perfect, but if the option is available to you, you could put your app in its own user/group. If there is an existing socket path and you don't own it then don't unlink it and put out an error message and letting the user or sysadmin sort it out. Using a config file to make it easily changeable - and available to clients - might work. Beyond that you almost have to go some kind of discovery service, which seems like massive overkill unless this is a really critical application.

    On the whole you can take some comfort that this doesn't actually happen often.

    0 讨论(0)
提交回复
热议问题