<div dir="auto">Hello guys,<div dir="auto"><br></div><div dir="auto">The process may crash, or other may misconfig and cause the file confliction.<div dir="auto">But at least, unit should remove the  pipe file on exit,as it already does to the control pipe.</div><div dir="auto"> </div><div dir="auto">So a patch should remove the Unix pipe on stop , instead of on startup.</div><div dir="auto"><br></div><div dir="auto">Can we agree on this?</div><div dir="auto"><br></div><div dir="auto">Thanks & Best Regards</div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Apr 2022, 05:45 Oleg A. Mamontov, <<a href="mailto:oleg@mamontov.net">oleg@mamontov.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Apr 27, 2022 at 05:11:26AM +1000, Scott van Kalken wrote:<br>
>This will work well for cases where unit shuts down gracefully. If unit does<br>
>not shut down gracefully, then i think you will have the same startup problem. <br>
><br>
>It’s a good point about the TCP socket. <br>
<br>
It seems the key point is the way to check on startup whether the unix<br>
socket is stale or currently in use and then to decide remove it and<br>
re-create or just fail the start, isn't it? <br>
<br>
>On Tue, 26 Apr 2022 at 11:50 am, <<a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a>> wrote:<br>
><br>
>    I have reconsided the situation:<br>
>    compare to TCP sockets, if a TCP bind fails, we know other programs are<br>
>    using the socket ,the ops team then fix the mis-configured port number,<br>
>    change unit or other programs.<br>
>    the unix socket should behave similarly.<br>
>    the diffrence is when a tcp server is done, the socket is recycled by<br>
>    system, while the unix socket file is left in disk, which block "unit"'s<br>
>    next boot.<br>
>    may the idea patch is to unlink the unix socket file on shutdown,<br>
>    instead of startup?<br>
><br>
><br>
>    On 2022-04-25 14:38,Scott van Kalken wrote:<br>
>    > What if it were a command line option to delete on start? This way you<br>
>    > preserve the existing behaviour while introducing the desired<br>
>    > behaviour. It’s up to the user / admin to decide if they want to<br>
>    > “force delete” as an example.<br>
>    ><br>
>    > On Mon, 25 Apr 2022 at 4:33 pm, <<a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a>> wrote:<br>
>    ><br>
>    >> I know the concern, that if we misconfigure the socket file, other<br>
>    >> file<br>
>    >> may be deleted accidentally.<br>
>    >> But if the program wont delete the file, bind will fail , that means<br>
>    >> we<br>
>    >> have to delete the file manually before every start. that not a good<br>
>    >><br>
>    >> option to maintain a system.<br>
>    >><br>
>    >> 在 2022-04-24 18:05,Александр Поволоцкий<br>
>    >> wrote:<br>
>    >>> Unlink socket that can be in use? I think it's not a good idea.<br>
>    >>><br>
>    >>> On 24.04.2022 12:25, <a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a> wrote:<br>
>    >>>><br>
>    >>>> hello,guys,<br>
>    >>>><br>
>    >>>> We found if we add a unix socket listener, the file was left in<br>
>    >> disk<br>
>    >>>> when unit got shutdown.<br>
>    >>>> If the unit starts again and load configuration from its state<br>
>    >> folder,<br>
>    >>>> it would fail with error msg "file exists",<br>
>    >>>> so We think the proper process is to "delete the legacy unix<br>
>    >> socket<br>
>    >>>> before start", and we present following patch:<br>
>    >>>><br>
>    >>>><br>
>    >>>> # HG changeset patch<br>
>    >>>> # User stdanley <<a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a>><br>
>    >>>> # Date 1650792235 -28800<br>
>    >>>> #      Sun Apr 24 17:23:55 2022 +0800<br>
>    >>>> # Node ID 29738840c393f12c7d7aa8f3959ed1655b39cd4d<br>
>    >>>> # Parent  8e06a879600e83af11345d023c53c2ca445cf82c<br>
>    >>>> unlink legacy unix socket file before binding.<br>
>    >>>><br>
>    >>>> diff -r 8e06a879600e -r 29738840c393 src/nxt_main_process.c<br>
>    >>>> --- a/src/nxt_main_process.c    Tue Apr 12 04:16:00 2022 +0100<br>
>    >>>> +++ b/src/nxt_main_process.c    Sun Apr 24 17:23:55 2022 +0800<br>
>    >>>> @@ -1142,6 +1142,15 @@<br>
>    >>>> }<br>
>    >>>><br>
>    >>>> #endif<br>
>    >>>> +#if (NXT_HAVE_UNIX_DOMAIN)<br>
>    >>>> +<br>
>    >>>> +    if (sa->u.sockaddr.sa_family == AF_UNIX<br>
>    >>>> +        && sa->type == SOCK_STREAM<br>
>    >>>> +        && sa->u.sockaddr_un.sun_path[0] != '\0') {<br>
>    >>>> +<br>
>    >>>> +        (void) unlink(sa->u.sockaddr_un.sun_path);<br>
>    >>>> +}<br>
>    >>>> +#endif<br>
>    >>>><br>
>    >>>> if (bind(s, &sa->u.sockaddr, sa->socklen) != 0) {<br>
>    >>>> err = nxt_errno;<br>
>    >>>> _______________________________________________<br>
>    >>>> unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
>    >>>> To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
>    >>> _______________________________________________<br>
>    >>> unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
>    >>> To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
>    >> _______________________________________________<br>
>    >> unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
>    >> To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
>    > _______________________________________________<br>
>    > unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
>    > To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
><br>
<br>
>_______________________________________________<br>
>unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
>To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
<br>
<br>
-- <br>
Cheers,<br>
Oleg A. Mamontov<br>
<br>
mailto: <a href="mailto:oleg@mamontov.net" target="_blank" rel="noreferrer">oleg@mamontov.net</a><br>
<br>
skype:  lonerr11<br>
cell:   +7 (903) 798-1352<br>
_______________________________________________<br>
unit mailing list -- <a href="mailto:unit@nginx.org" target="_blank" rel="noreferrer">unit@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:unit-leave@nginx.org" target="_blank" rel="noreferrer">unit-leave@nginx.org</a><br>
</blockquote></div>