Workaround of race condition between systemd and nginx.

Gena Makhomed gmm at csdoc.com
Thu Dec 31 05:05:40 UTC 2015


On 30.12.2015 22:40, Daniel K. wrote:

>> nginx failed to start if network is down via systemd race condition.

> Again, no, nginx failed to start due to a local misconfiguration.

Configuration is correct.

"nginx -t" syntax check say:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

>>> listen 172.22.22.202:80;

>> this is allowed syntax:
>> http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

> I never said it wasn't.

You say about "misconfiguration".

>>> And that, due to using systemd, the nginx service gets started before
>>> the network-interface have been configured with the IP address shown.
>>
>> Yes. And nginx failed to start with *correct* config.
>
> Well, syntactically correct, and logically correct is not the same thing.

My config is syntactically correct *and* it is logically correct too.

> Your config makes nginx try to bind to a non-assigned IP address,
> which fails. A logical error in your config files.

No. A logical error in nginx unit file
or in systemd source code or in nginx source code.

Result of error is race condition between systemd and nginx.
The simplest workaround of race condition is to fix nginx unit file.

>> And I should send this text fragment to all nginx users?
>
> I don't know what you should do, I feel like I am still missing a part
> of the puzzle.

Yes.

OpenVZ used by hosting providers on multiple hardware nodes.

Not always possible use only "listen 80;" and "listen 443;" directives.

> Arguably not better. The link you provided (repeated for context) tells
> you this on using network-online.target.
>
> http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
>
>    It is strongly recommended not to pull in this target too liberally:
>    [...] network server software should generally not pull this in

"should generally not pull this in".

Workaround is not "generally".

> There you have it; the systemd folks tell us that your suggested
> workaround is not a good idea to use for server software.

Systemd folks tell me and other nginx developers how *exactly* nginx
should work. You have time and money to rewrite core parts of nginx?

-- 
Best regards,
  Gena



More information about the nginx-devel mailing list