Re: Workaround of race condition between systemd and nginx.

[Jim Popovitch]

On Dec 30, 2015 12:44 PM, "Gena Makhomed" <g...@csdoc.com> wrote:
>
> On 30.12.2015 19:08, Jim Popovitch wrote:
>
>>> Do you know how nginx and systemd work right now?
>>> You understand race condition between nginx and systemd?
>
>
>> I understand nginx, systemd, and race conditions.  I understand why
>> *you* have a race condition, and I understand why I do not have a race
>> condition.
>
>
> And you want to tell this "mantra" to all OpenVZ / CentOS 7.2 users?
>
>
>>> You say, what nginx should work fine if no network available,
>
>
>> Yes, or even if only localhost (lo) exists.
>
>
> lo exists.
>
> nginx startup failed.
>
> logs - see in previous messages.
>
>
>> BTW, you can read about how openvpn handled this very issue
>> https://community.openvpn.net/openvpn/ticket/462
>
>
> You can provide patch with solution?

I see no need for a patch, and I already explained why, including a link to
how another service daemon handled the very same issue.   I've also
explainec how your patch breaks things.  Good day.

-Jim P.
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Workaround of race condition between systemd and nginx.

[Jim Popovitch]

On Wed, Dec 30, 2015 at 11:50 AM, Gena Makhomed <g...@csdoc.com> wrote:
> On 30.12.2015 18:09, Jim Popovitch wrote:
>
>>> nginx now requires configured and up network, before starting daemon.
>
>
>> Specifically it's your configuration.
>> You are hardcoding an IP address to bind to
>> thereby telling nginx to not start until that IP is active.
>
>
> Do you know how nginx and systemd work right now?
> You understand race condition between nginx and systemd?

I understand nginx, systemd, and race conditions.  I understand why
*you* have a race condition, and I understand why I do not have a race
condition.

>> That will prevent nginx from staring in situations where systemd
>> determines that the external network is not yet active (dhcp, etc.,
>> etc), yet nginx may still run perfectly fine with split interfaces,
>> localhost, etc.
>
>
> You say, what nginx should work fine if no network available,

Yes, or even if only localhost (lo) exists.

BTW, you can read about how openvpn handled this very issue
https://community.openvpn.net/openvpn/ticket/462

> I say what nginx *must* work fine if network *IS* available.

It does, it currently works if the network IS or ISNT available, and
all possibilities in-between.

>
> So, I need create my own fork, for example, nginx-fixed,
> which I can use with OpenVZ and CentOS 7.2 templates?

No, you can simply modify your local /etc/systemd/system/nginx.service
file to specify a local startup policy.


-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Workaround of race condition between systemd and nginx.

[Jim Popovitch]

On Wed, Dec 30, 2015 at 10:50 AM, Gena Makhomed  wrote:
> nginx now requires configured and up network, before starting daemon.

Specifically it's your configuration.  You are hardcoding an IP
address to bind to, thereby telling nginx to not start until that IP
is active.

> Replace network.target with network-online.target is easy workaround.

That will prevent nginx from staring in situations where systemd
determines that the external network is not yet active (dhcp, etc.,
etc), yet nginx may still run perfectly fine with split interfaces,
localhost, etc.

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Sub filter: support of multiple strings to replace.

[Jim Popovitch]

On Tue, Aug 18, 2015 at 12:56 PM, Dmitry xei...@nginx.com wrote:


 On 18.08.2015 19:44, Jim Popovitch wrote:

 On Tue, Aug 18, 2015 at 12:37 PM, Valentin V. Bartenev vb...@nginx.com
 wrote:

 On Tuesday 18 August 2015 12:08:12 Jim Popovitch wrote:

 On Mon, Aug 17, 2015 at 10:44 AM, Dmitry Volyntsev xei...@nginx.com
 wrote:

 details:   http://hg.nginx.org/nginx/rev/b9447fc457b4
 branches:
 changeset: 6228:b9447fc457b4
 user:  Dmitry Volyntsev xei...@nginx.com
 date:  Mon Aug 17 17:42:02 2015 +0300
 description:
 Sub filter: support of multiple strings to replace.

 Hello,

 Can you please provide an example of use.

 Thank you!

 See an example in the module documentation:
 http://nginx.org/en/docs/http/ngx_http_sub_module.html

 Thanks, I am aware of that.  What is missing from the docs is the
 format for multiple sub_filter entries.

 Is it:

 a) sub_filter matchA replaceA matchB replaceB;

 b) sub_filter matchA replaceA
   sub_filter matchB replaceB

 c) sub_fitler match1 match2 match3 replaceAll

 d) Only 1 sub_filter allowed per location or server

 Only this option is applicable here.


 And then there's the issue of sub_filter_last_modified and
 sub_filter_once applying to all, or just the preceding or the
 following entry?

 sub_filter_once on;  is designed to support configurations like this
 one:

 sub_filter 'head 'headlink ...';
 sub_filter 'body 'bodyscript ...';

 Here, each replacement will be applied only once.


Thank you very much Dmitry

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Sub filter: support of multiple strings to replace.

[Jim Popovitch]

On Tue, Aug 18, 2015 at 1:07 PM, Valentin V. Bartenev vb...@nginx.com wrote:

 Could you elaborate what exactly is unclear from the docs
 with citations?  Then we will be able to improve it.

It looks like the docs were just updated, or perhaps I didn't clear my
browser cache often enough.  :-)   I don't believe any changes are
necessary now, and thank you for providing an example in the docs.

 And I don't really understand the confusion about the
 sub_filter_last_modified directive, since it related to
 the response header, not sub_filter directives.

That was just an oversight on my part, I was mostly concerned with how
sub_filter_once would apply to multiple sub_filter entries and that
was cleared up by Dmitry.

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Sub filter: support of multiple strings to replace.

[Jim Popovitch]

On Tue, Aug 18, 2015 at 12:37 PM, Valentin V. Bartenev vb...@nginx.com wrote:
 On Tuesday 18 August 2015 12:08:12 Jim Popovitch wrote:
 On Mon, Aug 17, 2015 at 10:44 AM, Dmitry Volyntsev xei...@nginx.com wrote:
  details:   http://hg.nginx.org/nginx/rev/b9447fc457b4
  branches:
  changeset: 6228:b9447fc457b4
  user:  Dmitry Volyntsev xei...@nginx.com
  date:  Mon Aug 17 17:42:02 2015 +0300
  description:
  Sub filter: support of multiple strings to replace.
 

 Hello,

 Can you please provide an example of use.

 Thank you!


 See an example in the module documentation:
 http://nginx.org/en/docs/http/ngx_http_sub_module.html


Thanks, I am aware of that.  What is missing from the docs is the
format for multiple sub_filter entries.

Is it:

a) sub_filter matchA replaceA matchB replaceB;

b) sub_filter matchA replaceA
 sub_filter matchB replaceB

c) sub_fitler match1 match2 match3 replaceAll

d) Only 1 sub_filter allowed per location or server

And then there's the issue of sub_filter_last_modified and
sub_filter_once applying to all, or just the preceding or the
following entry?

Multiple sub_filters is a great addition, docs are unclear on usage.  :-)

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [nginx] Sub filter: support of multiple strings to replace.

[Jim Popovitch]

On Mon, Aug 17, 2015 at 10:44 AM, Dmitry Volyntsev xei...@nginx.com wrote:
 details:   http://hg.nginx.org/nginx/rev/b9447fc457b4
 branches:
 changeset: 6228:b9447fc457b4
 user:  Dmitry Volyntsev xei...@nginx.com
 date:  Mon Aug 17 17:42:02 2015 +0300
 description:
 Sub filter: support of multiple strings to replace.


Hello,

Can you please provide an example of use.

Thank you!

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: proxy_pass behavior

[Jim Popovitch]

On Fri, Mar 28, 2014 at 8:20 AM, Maxim Dounin mdou...@mdounin.ru wrote:
 Hello!

 On Thu, Mar 27, 2014 at 08:18:48PM -0400, Jim Popovitch wrote:

 On Thu, Mar 27, 2014 at 1:50 PM, Jim Popovitch jim...@gmail.com wrote:
  On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin mdou...@mdounin.ru wrote:
  Hello!
 
  On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote:
 
  On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru 
  wrote:
   Hello!
  
   On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote:
  
   Should proxy_pass retry ipv4 if ipv6 fails?   Currently (1.5.12), it
   does not, and there is no way to force proxy_pass to always use ipv4.
  
   In no particular order:
  
   - The proxy_next_upstream is expected to retry by default.
 
  Yes, that works if the host name has 2 or more A  OR  2 or more 
  records.  proxy_next_upstream does not appear to transition to the
  next protocol (i.e. from ipv4 to ipv6)
 
  It doesn't care about address family.  As long as connect() to
  one address fails, it will try next one.
 
  I will have to do some more tests, but so far 1.5.12 (debian wheezy)
  does not appear to try the next one if the next one is a different
  protocol family.

 So here is what happens:

 Nginx 1.5.12 on Debian Wheezy 7.4

 ~$ host www.acadiau.ca
 www.acadiau.ca has address 131.162.201.18
 www.acadiau.ca has IPv6 address 2620:21:c000:c8:0:aca:d1a:18

 ~$ grep proxy_pass /etc/nginx/sites-available/proxy
 proxy_pass https://www.acadiau.ca;

 When an IPv6 client connects to the proxy, proxy_pass logs the error as

 2014/03/27 21:28:28 [alert] 24862#0: *158336 connect() failed (13:
 Permission denied) while connecting to upstream, client:
 2604:180::82c6:fe9, server: proxy-service.tld, request: GET /
 HTTP/1.1, upstream: https://[2620:21:c000:c8:0:aca:d1a:18]:443/;,
 host: proxy-service.tld

 It will next try the ipv4 addr and succeed, however the reason for the

 So the original claim that it does not appear to try the next
 one is withdrawn, right?

99% of it is, I did see it fail once.

 Permission denied error appears to be the format of the URL (raw
 ipv6 addr, not hostname).  Why is it using the ipv6 addr instead of
 the hostname?

 No, it's an error from connect() syscall, returned by your OS for
 some reason (likely because there is no route available, or due to
 a firewall rule).  The address is one of the upstream server nginx
 uses at the moment - it's is vital for logging if there are more
 than one address.

I agree it's vital for logging so that you can see which address
failed.  It's just not clear that the destination server was presented
with the hostname (SNI) because the Permission denied message seems
to idicate connect() was successful but the resource was denied (due
to permissions).   But I can live with bad OS level error messages as
long as the behavior is accurate.

Thank you Maxim,

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

proxy_pass behavior

[Jim Popovitch]

Hello,

Should proxy_pass retry ipv4 if ipv6 fails?   Currently (1.5.12), it
does not, and there is no way to force proxy_pass to always use ipv4.

Specifically, if a proxy_pass host has dual records (A+),
proxy_pass seems to only try the .

I'm considering submitting a patch if there is support for this.

Thanks!

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: proxy_pass behavior

[Jim Popovitch]

On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote:
 Hello!

 On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote:

 Should proxy_pass retry ipv4 if ipv6 fails?   Currently (1.5.12), it
 does not, and there is no way to force proxy_pass to always use ipv4.

 In no particular order:

 - The proxy_next_upstream is expected to retry by default.

Yes, that works if the host name has 2 or more A  OR  2 or more 
records.  proxy_next_upstream does not appear to transition to the
next protocol (i.e. from ipv4 to ipv6)

 - There _is_ a way to force proxy_pass to always use ipv4 - you
   should configure your system accordingly, and
   getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right
   thing.  E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set
   to disable use of ipv6.

:-)  That's unacceptable!!  :-)   I don't want people to disable ipv6,
I want proxy_pass to use ipv6 and upon failure use ipv4.  ;-)

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: proxy_pass behavior

[Jim Popovitch]

On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin mdou...@mdounin.ru wrote:
 Hello!

 On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote:

 On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote:
  Hello!
 
  On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote:
 
  Should proxy_pass retry ipv4 if ipv6 fails?   Currently (1.5.12), it
  does not, and there is no way to force proxy_pass to always use ipv4.
 
  In no particular order:
 
  - The proxy_next_upstream is expected to retry by default.

 Yes, that works if the host name has 2 or more A  OR  2 or more 
 records.  proxy_next_upstream does not appear to transition to the
 next protocol (i.e. from ipv4 to ipv6)

 It doesn't care about address family.  As long as connect() to
 one address fails, it will try next one.

I will have to do some more tests, but so far 1.5.12 (debian wheezy)
does not appear to try the next one if the next one is a different
protocol family.

  - There _is_ a way to force proxy_pass to always use ipv4 - you
should configure your system accordingly, and
getaddrinfo(AI_ADDRCONFIG) as used by nginx will do the right
thing.  E.g., on Linux net.ipv6.conf.all.disable_ipv6 can be set
to disable use of ipv6.

 :-)  That's unacceptable!!  :-)   I don't want people to disable ipv6,
 I want proxy_pass to use ipv6 and upon failure use ipv4.  ;-)

 It was you who claimed that there is no way to force proxy_pass
 to always use ipv4.  There is.

What I was trying to claim was that there is no way to run nginx on
ipv4 and ipv6 yet force proxy_pass to use only ipv4.  Of course you
can proxy bind to a v4 interface, but that doesn't scale with syncing
configs to multiple servers.   Maybe it's time for a proxy_protocol
variable.

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [PATCH] SPDY/3.1 protocol implementation

[Jim Popovitch]

On Mon, Jan 27, 2014 at 3:02 PM, Valentin V. Bartenev vb...@nginx.com wrote:
 http://nginx.org/patches/patch.spdy-v31.txt

 This patch upgrades implementation of SPDY protocol in the
 ngx_http_spdy_module from draft 2 to draft 3.1.

 I am going to commit it at the end of this week. Till then,
 testing, review and suggestions are very much appreciated.

Woohoo!  Thank you.  Successfully applies to 1.5.9 and works as expected.

Thanks!

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

v1.5.9 compiled size is 8x larger than v1.5.8

[Jim Popovitch]

Hello,

I'm seeing a strange problem with v1.5.9, the compiled binary is 8
times larger than it was on v1.5.8.   My build environment (debian) is
the same that I've used for v1.5.8.

Production:
~$ nginx -V
nginx version: nginx/1.5.8
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid
--with-pcre-jit --with-http_gzip_static_module --with-http_ssl_module
--with-http_spdy_module --with-ipv6 --without-http_browser_module
--without-http_geo_module --without-http_limit_req_module
--without-http_limit_zone_module --without-http_memcached_module
--without-http_referer_module --without-http_scgi_module
--without-http_split_clients_module --with-http_stub_status_module
--without-http_ssi_module --without-http_userid_module
--without-http_uwsgi_module
~$ ls -al /usr/sbin/nginx
-rwxr-xr-x 1 root root 613080 Dec 30 19:15 /usr/sbin/nginx


Testbed:
~$ nginx -V
nginx version: nginx/1.5.9
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi
--http-log-path=/var/log/nginx/access.log
--http-proxy-temp-path=/var/lib/nginx/proxy
--lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid
--with-pcre-jit --with-http_gzip_static_module --with-http_ssl_module
--with-http_spdy_module --with-ipv6 --without-http_browser_module
--without-http_geo_module --without-http_limit_req_module
--without-http_limit_zone_module --without-http_memcached_module
--without-http_referer_module --without-http_scgi_module
--without-http_split_clients_module --with-http_stub_status_module
--without-http_ssi_module --without-http_userid_module
--without-http_uwsgi_module
~$ ls -al /usr/sbin/nginx
-rwxr-xr-x 1 root root 5226396 Jan 22 16:11 /usr/sbin/nginx


What could be causing the increased binary size?

Thank you,

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: v1.5.9 compiled size is 8x larger than v1.5.8

[Jim Popovitch]

On Wed, Jan 22, 2014 at 3:23 PM, Ruslan Ermilov r...@nginx.com wrote:
 Could it be that you lost some shared library that nginx uses?

 For the starters, compare the outputs of file /usr/sbin/nginx
 (are both binaries are stripped) and ldd /usr/sbin/nginx (do
 they show the same shared libs)?

Hmmm, the 2 environments (Production and Testbed) are identical,
Debian 7.3 x86_64.

Production (v1.5.8):
~$ file /usr/sbin/nginx
/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0xe63406c0f961166e7b17abd320290fb2c8e976ee, stripped
~$ ldd /usr/sbin/nginx
linux-vdso.so.1 =  (0x7fffc67ff000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9e6d744000)
libcrypt.so.1 = /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7f9e6d50d000)
libpcre.so.3 = /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f9e6d2cf000)
libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x7f9e6d06f000)
libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7f9e6cc8b000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9e6ca86000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f9e6c86f000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f9e6c4e5000)
/lib64/ld-linux-x86-64.so.2 (0x7f9e6d965000)


Testbed (v1.5.9)
~$ file /usr/sbin/nginx
/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x38b6c11381d456bce11faaa5c5178f68886816a5, not stripped
~$ ldd /usr/sbin/nginx
linux-vdso.so.1 =  (0x7fff24d4a000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb3a7424000)
libcrypt.so.1 = /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fb3a71ed000)
libpcre.so.3 = /lib/x86_64-linux-gnu/libpcre.so.3 (0x7fb3a6faf000)
libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x7fb3a6d4f000)
libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7fb3a696b000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb3a6766000)
libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fb3a654f000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fb3a61c5000)
/lib64/ld-linux-x86-64.so.2 (0x7fb3a7645000)

-Jim P.

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel