[WIP/RFC v4 0/5] Support abstract Unix sockets

[Alejandro Colomar]

Hi Maxim,

On 8/24/22 16:58, Maxim Dounin wrote:
> Hello!
> 
> On Wed, Aug 24, 2022 at 01:00:26AM +0200, Alejandro Colomar wrote:
> 
>> I'll resend v4 in a moment, since it didn't arrive to the list.
>>
>> On 8/23/22 23:18, Alejandro Colomar wrote:
>>> Hi,
>>>
>>> Patch set ready for review.
>>> Both 'listen' and 'proxy_pass' work fine, with the only caveat
>>> that writing a NUL character in the nginx.conf file is not the
>>> friendliest interface.  I will add a few more patches to make '@'
>>> a synonym for NUL, as many other projects do.
>>>
>>> However, this patch set can be applied on its own if you prefer
>>> to make them separate, since this one adds the feature in its
>>> simplest way, and the upcoming patches are just making it more
>>> user friendly.  Please advice on your preferred way of proceeding.
> 
> A while ago a working implementation of Linux abstract namespace
> sockets was already posted in this mailing list, see here:
> 
> https://mailman.nginx.org/pipermail/nginx-devel/2016-October/008878.html
> 
> It received zero interest and no tests/reviews, hence there are
> no further work on this.

I didn't know about that one, but found two others (one from 2012 and 
another from 2019).  I based my v1 on the 2019 one, but then decided 
that I didn't like it and rewrote it from scratch.

> 
> If you think that Linux abstract namespace support is needed, you
> may want to start with basic things, notably:
> 
>> Try to make it clear why the suggested change is needed, and
>> provide a use case, if possible.

Yeah, that's the most important thing.  I mentioned it in v1, which also 
didn't reach the mailing list :(.  I'll restate here.

For having nginx as a reverse proxy in front of a server, such as unit, 
it's faster to communicate through Unix sockets (UDS), rather than TCP 
(localhost).  Nginx already supports UDS.  But UDS has a problem: the 
kernel creates a file in the fs, and it's not always trivial to clean up 
those files.  Then, if the application is restarted, there's no 
SO_REUSEADDR to allow reusing the socket file, so the application will 
just fail.

This happens in nginx Unit, which creates listener sockets from a 
privileged thread, and then uses them from unprivileged threads.  When 
the unprivileged thread stops using the socket, it can't remove the 
file, and doing so would require huge complexity to implement.  It's 
easier to just tell the kernel we want an abstract UDS (AUDS), so that 
there's no file at all.  Then if the user restarts Unit, it'll be able 
to recreate the AUDS.

A user reported this problem with normal UDS and we concluded that the 
easiest solution would be to add support for AUDS.  His set-up is a 
kubernetes pod, where a container uses nginx and another container uses 
Unit.  Communicating through an AUDS would be trivial and fast.

> 
> (Quote from http://nginx.org/en/docs/contributing_changes.html)
> 
> That is, please clarify how do you expect to use it, and why
> existing options does not work for you.

About how I expect to use it, sorry for the mess of emails; I sent one 
email with a complete example, but the list rejected it, and so I 
replied to it so that the list received it, but now this whole email 
thread is a bit messy.  Maybe I should send a clean v5 that is 
self-contained.

To simplify, the usage I want to support is:

listen unix:@foo

and

proxy_pass http://unix:@bar


But for now in v4 I have an intermediate solution that is exactly as 
above but replacing the @ by the NUL character.  When I add support for 
@, NUL will continue working, but I wouldn't document that; it's just an 
implementation detail.

Cheers,

Alex

> 

-- 
Alejandro Colomar
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20220824/63d1fa49/attachment.bin>