Hello!
On Tue, Sep 18, 2018 at 08:12:20AM -0400, Thomas Ward wrote:
> Downstream in Ubuntu, it has been proposed to demote pcre3 and
> use pcre2 instead as it is newer.
> https://trac.nginx.org/nginx/ticket/720 shows it was marked 4
> years ago that NGINX does not support pcre2. Are there any
> plans to use pcre2 instead of pcre3?
There are no immediate plans.
When we last checked, there were no problems with PCRE, but PCRE2
wasn't available in most distributions we support, making the
switch mostly meaningless.
Also, it looks like PCRE2 is still not supported even by Exim,
which is the parent project of PCRE and PCRE2:
https://bugs.exim.org/show_bug.cgi?id=1878
As such, adding PCRE2 support to nginx looks premature.
--
Maxim Dounin
http://mdounin.ru/
Hello,
as an Nginx user, I regularly discover new features that prove useful if not game changers.
However I stay puzzled (nearly since I started using it) on why the config include system does not allow relative paths, that is, relative to the currently parsed file. This would allow for simple modular config designs, where a "main" server config file can embed the snippets that are deployed next to it.
The only tips I see on the forums and so is "hey, just use a templating system to absolutize every include at deployment time", which takes us away from Nginx' KISS philosophy.
In an ideal world, my production nginx.conf would only include /var/www/*/app.conf, and I could drop my "blorp" web app (that I developed on /home/gui/www/blorp) in /var/www and have it running at the next nginx reload, with it correctly loading every location /xxx { include inc/phpfpm.conf; } of its app.conf.
For now, I either have to centralize the snippets in /etc/nginx/inc/phpfpm.conf (thus when a new rule has to be added my developer has to tell my system operator to apply the change to the centralized file), or inline the snippets in the (then monolithic) app.conf (hey, duplication!), or hardcode the snippet's path as /var/www/blorp/inc/phpfpm.conf (and symlink it on my dev machine so that prod and dev config files are shared?), or better make the app.conf a template and fill absolute paths at deployment, so that if I want to run my shiny new version of blorp as blorp-ng along blorp it does not include the old version's phpfpm.conf erronously.
The following patch adds a simple heuristic to include: if the includee starts with "./", it is considered relative to the current file. If not, the current heuristic applies (paths stay relative to the prefix).
I would be interested in learning the flaws or drawbacks in this (bad?) idea. I first thought "security", (disallowing relative includes keeps included files under control in config's root), but anyhow, either you keep total control on the config (and are on your responsibility to not include anything out of the conf tree) or give the web app's developer a hook to load its app-required snippets, and then nothing prevents him to include whatever he wants.
--
Guillaume
# HG changeset patch
# User Guillaume Outters <guillaume-nginx(a)outters.eu>
# Date 1567058353 -7200
# Thu Aug 29 07:59:13 2019 +0200
# Node ID 704100d8a8772a4bc2faaef9abcc0308316e580c
# Parent 9f1f9d6e056a4f85907957ef263f78a426ae4f9c
ngx_conf_file: "include ./" acts relative to currently parsed file
Allow configuration files to include relatively to them instead of to prefix.
Eases modular configurations, where includees do not need to know their
absolute path to reach helper config files next to them.
diff -r 9f1f9d6e056a -r 704100d8a877 src/core/ngx_conf_file.c
--- a/src/core/ngx_conf_file.c Mon Aug 19 15:16:06 2019 +0300
+++ b/src/core/ngx_conf_file.c Thu Aug 29 12:59:13 2019 +0200
@@ -15,6 +15,7 @@
static ngx_int_t ngx_conf_read_token(ngx_conf_t *cf);
static void ngx_conf_flush_files(ngx_cycle_t *cycle);
+ngx_int_t ngx_conf_full_name_rel(ngx_cycle_t *cycle, ngx_str_t *name, ngx_uint_t conf_prefix, ngx_str_t *current);
static ngx_command_t ngx_conf_commands[] = {
@@ -830,7 +831,7 @@
ngx_log_debug1(NGX_LOG_DEBUG_CORE, cf->log, 0, "include %s", file.data);
- if (ngx_conf_full_name(cf->cycle, &file, 1) != NGX_OK) {
+ if (ngx_conf_full_name_rel(cf->cycle, &file, 1, &cf->conf_file->file.name) != NGX_OK) {
return NGX_CONF_ERROR;
}
@@ -884,16 +885,39 @@
ngx_int_t
-ngx_conf_full_name(ngx_cycle_t *cycle, ngx_str_t *name, ngx_uint_t conf_prefix)
+ngx_conf_full_name_rel(ngx_cycle_t *cycle, ngx_str_t *name, ngx_uint_t conf_prefix, ngx_str_t *current)
{
ngx_str_t *prefix;
+ ngx_str_t local_prefix;
- prefix = conf_prefix ? &cycle->conf_prefix : &cycle->prefix;
+ /*
+ * Path starting with literal ./ is interpreted relative to current's
+ * directory instead of prefix.
+ */
+ if (name->len >= 2 && name->data[0] == '.' && name->data[1] == '/' && current && current->len && current->data[0] == '/') {
+ name->len -= 2;
+ name->data += 2;
+
+ local_prefix.data = current->data;
+ for (local_prefix.len = current->len; local_prefix.data[--local_prefix.len] != '/'; /* void */ ) /* void */ ;
+ ++local_prefix.len;
+ prefix = &local_prefix;
+
+ } else {
+ prefix = conf_prefix ? &cycle->conf_prefix : &cycle->prefix;
+ }
return ngx_get_full_name(cycle->pool, prefix, name);
}
+ngx_int_t
+ngx_conf_full_name(ngx_cycle_t *cycle, ngx_str_t *name, ngx_uint_t conf_prefix)
+{
+ return ngx_conf_full_name_rel(cycle, name, conf_prefix, NULL);
+}
+
+
ngx_open_file_t *
ngx_conf_open_file(ngx_cycle_t *cycle, ngx_str_t *name)
{
Hi all,
I noticed today that I'm missing something basic... I wanted to allocate some buffers that will live throughout the lifetime of the process =
not associated with any specific request. I believe I've already done something like that in the past, and I used the cycle pool for that.
However, after digging a bit in the code, I found that in single process mode, if nginx is reloaded, a new cycle is created and the
old one destroyed.
If my understanding is correct, this has many implications far exceeding the simple question I started with...
For example, since the configuration is allocated on the cycle pool, it means that modules should not read the configuration
of the request in any asynchronous callback, because there is a chance that the configuration was already freed since the request
object was created.
I then found this issue - https://trac.nginx.org/nginx/ticket/945 so I guess that this problem is known and ignored because
'master_process off' is only for dev, and no need to support reload there...
So, back to my original question... is using ngx_cycle->pool the correct way to allocate such "persistent" buffers?
Another option is to use ngx_alloc directly (if the process quits, it doesn't matter...), but cycle pool sounds a bit more elegant
(and won't have valgrind report leaks...)
Thank you!
Eran
Hello,
While browsing the source I noticed something that seemed wrong, even
though I haven't observed any buggy behavior or have reproduced this bug
myself. In ngx_event.c there is a line:
if (ngx_shmtx_create(&ngx_accept_mutex, (ngx_shmtx_sh_t *) shared,
cycle->lock_file.data)
!= NGX_OK)
{
return NGX_ERROR;
}
ngx_shmtx_create() is passed &ngx_accept_mutex, but this must be a
pointer to a shared memory region otherwise the sem_wait()/sem_post()
calls in ngx_shmtx.c will not function correctly. &ngx_accept_mutex is a
pointer to BSS, ngx_accept_mutex_ptr is a pointer to shared memory. Is
this intentional?
Rian