sane way of cleaning up stale unix sockets?

Valentin V. Bartenev vbart at nginx.com
Fri Jan 8 13:23:52 UTC 2021


No major obstacles, it just waits someone to rewrite the related code.

--
Valentin


On Tuesday, 5 January 2021 19:19:39 MSK Александр Поволоцкий wrote:
> Hello
> 
> Why nxt_listen_socket_create is not used to create sockets other than 
> control? Any positive reason or "still no time to rewrite?"
> 
> --
> 
> Alex
> 
> On 22.12.2020 17:40, Valentin V. Bartenev wrote:
> > Actually we thought about a connection test with the algorithm of atomic
> > creation of such sockets, that was implemented earlier this year for the
> > control socket: https://hg.nginx.org/unit/rev/0a8840921fd0
> >
> > --
> > Valentin
> >
> >
> >
> > On Tuesday, 22 December 2020 17:14:15 MSK Александр Поволоцкий wrote:
> >> Maybe just https://gavv.github.io/articles/unix-socket-reuse/ ?
> >>
> >> On 22.12.2020 17:12, Valentin V. Bartenev wrote:
> >>> On Saturday, 19 December 2020 18:48:02 MSK Александр Поволоцкий wrote:
> >>>> Hello
> >>>>
> >>>> Sometimes unitd leaves behind orphaned unix sockets (well, just
> >>>> configure it to use some and kill -9!)
> >>>>
> >>>> On next start, unitd fails to start because of existing sockets.
> >>>>
> >>>> Is there a sane way to clean up them on start? keeping separate list of
> >>>> sockets-to-remove is a clear way to insainty.
> >>> [..]
> >>>
> >>> Hello,
> >>>
> >>> Indeed, this is a problem.  That's the reason why the usage of unix sockets
> >>> in listeners is still undocumented.
> >>>
> >>> It's not so easy to fix, because we need to avoid the situation when the socket
> >>> is used by some other processes and avoid any possible race conditions
> >>> here.
> >>>
> >>> Actually, until it will be fixed I have no better idea than put them all in the
> >>> same dedicated directory and just clean up everything in it each restart.
> >>>
> >>>     wbr, Valentin V. Bartenev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> unit mailing list
> >>> unit at nginx.org
> >>> https://mailman.nginx.org/mailman/listinfo/unit
> >> _______________________________________________
> >> unit mailing list
> >> unit at nginx.org
> >> https://mailman.nginx.org/mailman/listinfo/unit
> >>
> >
> >
> >
> > _______________________________________________
> > unit mailing list
> > unit at nginx.org
> > https://mailman.nginx.org/mailman/listinfo/unit
> _______________________________________________
> unit mailing list
> unit at nginx.org
> https://mailman.nginx.org/mailman/listinfo/unit
> 






More information about the unit mailing list