History log of /unit/src/ (Results 151 – 175 of 1368)
Revision (<<< Hide revision tags) (Show revision tags >>>)Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
2262:0bca3af03c7524-Oct-2022 Andrew Clayton

Isolation: wired up cgroup support to the config system.

This hooks the cgroup support up to the config system so it can actually
be used.

To make use of this in unit a new "cgroup" section has bee

Isolation: wired up cgroup support to the config system.

This hooks the cgroup support up to the config system so it can actually
be used.

To make use of this in unit a new "cgroup" section has been added to the
isolation configuration.

e.g

"applications": {
"python": {
"type": "python",
"processes": 5,
"path": "/opt/unit/unit-cgroup-test/",
"module": "app",

"isolation": {
"cgroup": {
"path": "app/python"
}
}
}
}

Now there are two ways to specify the path, relative, like the above
(without a leading '/') and absolute (with a leading '/').

In the above case the "python" application is placed into its own cgroup
under CGROUP_ROOT/<main unit process cgroup>/app/python. Whereas if you
specified say

"path": "/unit/app/python"

Then the python application would be placed under
CGROUP_ROOT/unit/app/python

The first option allows you to easily take advantage of any resource
limits that have already been configured for unit.

With the second method (absolute pathname) if you know of an already
existing cgroup where you'd like to place it, you can, e.g

"path": "/system.slice/unit/python"

Where system.slice has already been created by systemd and may already
have some overall system limits applied which would also apply to unit.
Limits apply down the hierarchy and lower groups can't exceed the
previous group limits.

So what does this actually look like? Lets take the unit-calculator
application[0] and have each of its applications placed into their own
cgroup. If we give each application a new section like

"isolation": {
"cgroup": {
"path": "/unit/unit-calculator/add"
}
}

changing the path for each one, we can visualise the result with the
systemd-cgls command, e.g

│ └─session-5.scope (#4561)
│ ├─ 6667 sshd: andrew [priv]
│ ├─ 6684 sshd: andrew@pts/0
│ ├─ 6685 -bash
│ ├─ 12632 unit: main v1.28.0 [/opt/unit/sbin/unitd --control 127.0.0.1:808>
│ ├─ 12634 unit: controller
│ ├─ 12635 unit: router
│ ├─ 13550 systemd-cgls
│ └─ 13551 less
├─unit (#4759)
│ └─unit-calculator (#5037)
│ ├─subtract (#5069)
│ │ ├─ 12650 unit: "subtract" prototype
│ │ └─ 12651 unit: "subtract" application
│ ├─multiply (#5085)
│ │ ├─ 12653 unit: "multiply" prototype
│ │ └─ 12654 unit: "multiply" application
│ ├─divide (#5101)
│ │ ├─ 12671 unit: "divide" prototype
│ │ └─ 12672 node divide.js
│ ├─sqroot (#5117)
│ │ ├─ 12679 unit: "sqroot" prototype
│ │ └─ 12680 /home/andrew/src/unit-calculator/sqroot/sqroot
│ └─add (#5053)
│ ├─ 12648 unit: "add" prototype
│ └─ 12649 unit: "add" application

We used an absolute path so the cgroups will be created relative to the
main cgroupfs mount, e.g /sys/fs/cgroup

We can see that the main unit processes are in the same cgroup as the
shell from where they were started, by default child process are placed
into the same cgroup as the parent.

Then we can see that each application has been placed into its own
cgroup under /sys/fs/cgroup

Taking another example of a simple 5 process python application, with

"isolation": {
"cgroup": {
"path": "app/python"
}
}

Here we have specified a relative path and thus the python application
will be placed below the existing cgroup that contains the main unit
process. E.g

│ │ │ ├─app-glib-cinnamon\x2dcustom\x2dlauncher\x2d3-43951.scope (#90951)
│ │ │ │ ├─ 988 unit: main v1.28.0 [/opt/unit/sbin/unitd --no-daemon]
│ │ │ │ ├─ 990 unit: controller
│ │ │ │ ├─ 991 unit: router
│ │ │ │ ├─ 43951 xterm -bg rgb:20/20/20 -fg white -fa DejaVu Sans Mono
│ │ │ │ ├─ 43956 bash
│ │ │ │ ├─ 58828 sudo -i
│ │ │ │ ├─ 58831 -bash
│ │ │ │ └─app (#107351)
│ │ │ │ └─python (#107367)
│ │ │ │ ├─ 992 unit: "python" prototype
│ │ │ │ ├─ 993 unit: "python" application
│ │ │ │ ├─ 994 unit: "python" application
│ │ │ │ ├─ 995 unit: "python" application
│ │ │ │ ├─ 996 unit: "python" application
│ │ │ │ └─ 997 unit: "python" application

[0]: <https://github.com/lcrilly/unit-calculator>

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2260:3005b3de99a524-Oct-2022 Andrew Clayton

Isolation: wired up per-application cgroup support internally.

This commit hooks into the cgroup infrastructure added in the previous
commit to create per-application cgroups.

It does this by addin

Isolation: wired up per-application cgroup support internally.

This commit hooks into the cgroup infrastructure added in the previous
commit to create per-application cgroups.

It does this by adding each "prototype process" into its own cgroup,
then each child process inherits its parents cgroup.

If we fail to create a cgroup we simply fail the process. This behaviour
may get enhanced in the future.

This won't actually do anything yet. Subsequent commits will hook this
up to the build and config systems.

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2259:be0239db0ed924-Oct-2022 Andrew Clayton

Isolation: added core cgroup infrastructure.

Firstly, this is not to be confused with CLONE_NEWCGROUP which unit
already supports and is related to namespaces. To re-cap, namespaces
allow processes

Isolation: added core cgroup infrastructure.

Firstly, this is not to be confused with CLONE_NEWCGROUP which unit
already supports and is related to namespaces. To re-cap, namespaces
allow processes to have different views of various parts of the system
such as filesystem mounts, networking, hostname etc.

Whereas cgroup[0] is a Linux kernel facility for collecting a bunch of
processes together to perform some task on the group as a whole, for
example to implement resource limits.

There are two parts to cgroup, the core part of organising processes
into a hierarchy and the controllers which are responsible for enforcing
resource limits etc.

There are currently two versions of the cgroup sub-system, the original
cgroup and a version 2[1] introduced in 3.16 (August 2014) and marked
stable in 4.5 (March 2016).

This commit supports the cgroup V2 API and implements the ability to
place applications into their own cgroup on a per-application basis.
You can put them each into their own cgroup or you can group some
together. The ability to set resource limits can easily be added in
future.

The initial use case of this would be to aid in observability of unit
applications which becomes much easier if you can just monitor them on a
per cgroup basis.

One thing to note about cgroup, is that unlike namespaces which are
controlled via system calls such as clone(2) and unshare(2), cgroups are
setup and controlled through the cgroupfs pseudo-filesystem.

cgroup is Linux only and this support will only be enabled if configure
finds the cgroup2 filesystem mount, e.g

cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)

The cgroups are removed on shutdown or as required on reconfiguration.

This commit just adds the basic infrastructure for using cgroups within
unit. Subsequent commits will wire up this support.

It supports creating cgroups relative to the main cgroup root and also
below the cgroup of the main unit process.

[0]: <https://man7.org/linux/man-pages/man7/cgroups.7.html>
[1]: <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>

Cc: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2258:6ec8b42a818501-Dec-2022 Andrew Clayton

Added simple wrappers for fopen(3) and fclose(3).

Add simple wrapper functions for fopen(3) and fclose(3) that are
somewhat akin to the nxt_file_open() and nxt_file_close() wrappers that
log errors.

Added simple wrappers for fopen(3) and fclose(3).

Add simple wrapper functions for fopen(3) and fclose(3) that are
somewhat akin to the nxt_file_open() and nxt_file_close() wrappers that
log errors.

Suggested-by: Alejandro Colomar <alx@nginx.com>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2256:c5b061332c8306-Dec-2022 Andrew Clayton

Fix compilation with GCC and -O0.

Andrei reported an issue with building unit when using '-O0' with GCC
producing the following compiler errors

cc -c -pipe -fPIC -fvisibility=hidden -O -W -Wall -We

Fix compilation with GCC and -O0.

Andrei reported an issue with building unit when using '-O0' with GCC
producing the following compiler errors

cc -c -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-prototypes -Werror -g -O0 -I src -I build \
\
\
-o build/src/nxt_unit.o \
-MMD -MF build/src/nxt_unit.dep -MT build/src/nxt_unit.o \
src/nxt_unit.c
src/nxt_unit.c: In function ‘nxt_unit_log’:
src/nxt_unit.c:6601:9: error: ‘msg’ may be used uninitialized [-Werror=maybe-uninitialized]
6601 | p = nxt_unit_snprint_prefix(p, end, pid, level);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/nxt_unit.c:6682:1: note: by argument 2 of type ‘const char *’ to ‘nxt_unit_snprint_prefix’ declared here
6682 | nxt_unit_snprint_prefix(char *p, const char *end, pid_t pid, int level)
| ^~~~~~~~~~~~~~~~~~~~~~~
src/nxt_unit.c:6582:22: note: ‘msg’ declared here
6582 | char msg[NXT_MAX_ERROR_STR], *p, *end;
| ^~~
src/nxt_unit.c: In function ‘nxt_unit_req_log’:
src/nxt_unit.c:6645:9: error: ‘msg’ may be used uninitialized [-Werror=maybe-uninitialized]
6645 | p = nxt_unit_snprint_prefix(p, end, pid, level);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/nxt_unit.c:6682:1: note: by argument 2 of type ‘const char *’ to ‘nxt_unit_snprint_prefix’ declared here
6682 | nxt_unit_snprint_prefix(char *p, const char *end, pid_t pid, int level)
| ^~~~~~~~~~~~~~~~~~~~~~~
src/nxt_unit.c:6625:35: note: ‘msg’ declared here
6625 | char msg[NXT_MAX_ERROR_STR], *p, *end;
| ^~~
cc1: all warnings being treated as errors

The above was reproduced with

$ ./configure --cc-opt=-O0 && ./configure python && make -j4

This warning doesn't happen on clang (15.0.4) or GCC (8.3) and seems to
have been introduced in GCC 11. The above is from GCC (12.2.1, Fedora
37).

The trigger of this GCC issue is actually part of a commit I introduced
a few months back to constify some function parameters and it seems the
consensus for how to resolve this problem is to simply remove the const
qualifier from the *end parameter to nxt_unit_snprint_prefix().

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100417>
Link: <https://github.com/samtools/htslib/pull/1285>
Link: <https://gcc.gnu.org/gcc-11/changes.html>
Fixes: 4418f99 ("Constified numerous function parameters.")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2252:876de8d26f1c06-Dec-2022 Andrei Zeliankou

Node.js: added "shortCircuit" option for ES modules hook.

Starting from Node.js v18.6.0 return value from all hooks must have
"shortCircuit: true" option specified. For more information see:
https:

Node.js: added "shortCircuit" option for ES modules hook.

Starting from Node.js v18.6.0 return value from all hooks must have
"shortCircuit: true" option specified. For more information see:
https://github.com/nodejs/node/commit/10bcad5c6e

show more ...

2251:6e5a9550ead317-Nov-2022 Andrew Clayton

Python: Added support for Python 3.11.

Python 3.8 added a new Python initialisation configuration API[0].

Python 3.11 marked the old API as deprecated resulting in the following
compiler warnings w

Python: Added support for Python 3.11.

Python 3.8 added a new Python initialisation configuration API[0].

Python 3.11 marked the old API as deprecated resulting in the following
compiler warnings which we treat as errors, failing the build

src/python/nxt_python.c: In function ‘nxt_python_start’:
src/python/nxt_python.c:130:13: error: ‘Py_SetProgramName’ is deprecated [-Werror=deprecated-declarations]
130 | Py_SetProgramName(nxt_py_home);
| ^~~~~~~~~~~~~~~~~
In file included from /opt/python-3.11/include/python3.11/Python.h:94,
from src/python/nxt_python.c:7:
/opt/python-3.11/include/python3.11/pylifecycle.h:37:38: note: declared here
37 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetProgramName(const wchar_t *);
| ^~~~~~~~~~~~~~~~~
src/python/nxt_python.c:134:13: error: ‘Py_SetPythonHome’ is deprecated [-Werror=deprecated-declarations]
134 | Py_SetPythonHome(nxt_py_home);
| ^~~~~~~~~~~~~~~~
/opt/python-3.11/include/python3.11/pylifecycle.h:40:38: note: declared here
40 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetPythonHome(const wchar_t *);
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

We actually have a few config scenarios: Python < 3, Python >= 3.0 < 3.8
and for Python 3 we have two configs where we select one based on
virtual environment setup.

Factor out the Python 3 config initialisation into its own function. We
actually create two functions, one for Python 3.8+ and one for older
Python 3. We pick the right function to use at build time.

The new API also has error checking (where the old API doesn't) which we
handle.

[0]: https://peps.python.org/pep-0587/

Closes: <https://github.com/nginx/unit/issues/710>
[ Andrew: Expanded upon patch from @sandeep-gh ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2248:67f848571b9f22-Nov-2022 Zhidao HONG

NJS: added http request prototype.

2247:baa6b987926720-Nov-2022 Zhidao HONG

Basic njs support.

2246:5f405647837520-Nov-2022 Zhidao HONG

Var: separating nxt_tstr_t from nxt_var_t.

It's for the introduction of njs support.
For each option that supports native variable and JS template literals introduced next,
it's unified as template

Var: separating nxt_tstr_t from nxt_var_t.

It's for the introduction of njs support.
For each option that supports native variable and JS template literals introduced next,
it's unified as template string.

No functional changes.

show more ...

2243:dd668fe8d82720-Nov-2022 Zhidao HONG

Var: improved variable parsing with empty names.

Unit parsed the case of "$uri$$host" into unknown variables.
This commit makes it invalid variable instead.

2241:41f859efec4b06-Nov-2022 OutOfFocus4

Refactored functions that set WSGI variables.

Splitting `nxt_python_add_sptr` into several functions will make future
additions easier.

Signed-off-by: Alejandro Colomar <alx@nginx.com>

2240:0c49318572c213-Sep-2022 OutOfFocus4

Removed dead code.

Signed-off-by: Alejandro Colomar <alx@nginx.com>

2234:70ff684235b015-Nov-2022 Andrei Zeliankou

Optimization for the "--no-unix-sockets" case.

2232:1fb2182a4d0302-Nov-2022 Alejandro Colomar

Removed the unsafe nxt_memchr() wrapper for memchr(3).

The casts are unnecessary, since memchr(3)'s argument is 'const void *'.
It might have been necessary in the times of K&R, where 'void *' didn'

Removed the unsafe nxt_memchr() wrapper for memchr(3).

The casts are unnecessary, since memchr(3)'s argument is 'const void *'.
It might have been necessary in the times of K&R, where 'void *' didn't
exist. Nowadays, it's unnecessary, and _very_ unsafe, since casts can
hide all classes of bugs by silencing most compiler warnings.

The changes from nxt_memchr() to memchr(3) were scripted:

$ find src/ -type f \
| grep '\.[ch]$' \
| xargs sed -i 's/nxt_memchr/memchr/'

Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2231:5b3a69fd47a702-Nov-2022 Alejandro Colomar

Removed the unsafe nxt_memcmp() wrapper for memcmp(3).

The casts are unnecessary, since memcmp(3)'s arguments are 'void *'.
It might have been necessary in the times of K&R, where 'void *' didn't
ex

Removed the unsafe nxt_memcmp() wrapper for memcmp(3).

The casts are unnecessary, since memcmp(3)'s arguments are 'void *'.
It might have been necessary in the times of K&R, where 'void *' didn't
exist. Nowadays, it's unnecessary, and _very_ unsafe, since casts can
hide all classes of bugs by silencing most compiler warnings.

The changes from nxt_memcmp() to memcmp(3) were scripted:

$ find src/ -type f \
| grep '\.[ch]$' \
| xargs sed -i 's/nxt_memcmp/memcmp/'

Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2230:83b2d20d8f5c16-Sep-2022 Andrew Clayton

PHP: allowed to specify URLs without a trailing '/'.

Both @lucatacconi & @mwoodpatrick reported what appears to be the same
issue on GitHub. Namely that when using the PHP language module and
trying

PHP: allowed to specify URLs without a trailing '/'.

Both @lucatacconi & @mwoodpatrick reported what appears to be the same
issue on GitHub. Namely that when using the PHP language module and
trying to access a URL that is a directory but without specifying the
trailing '/', they were getting a '503 Service Unavailable' error.

Note: This is when _not_ using the 'script' option.

E.g with the following config

{
"listeners": {
"[::1]:8080": {
"pass": "applications/php"
}
},

"applications": {
"php": {
"type": "php",
"root": "/var/tmp/unit-php"
}
}
}

and with a directory path of /var/tmp/unit-php/foo containing an
index.php, you would see the following

$ curl http://localhost/foo
<title>Error 503</title>
Error 503

However

$ curl http://localhost/foo/

would work and serve up the index.php

This commit fixes the above so you get the desired behaviour without
specifying the trailing '/' by doing the following

1] If the URL doesn't end in .php and doesn't have a trailing '/'
then check if the requested path is a directory.

2) If it is a directory then create a 301 re-direct pointing to it.
This matches the behaviour of the likes of nginx, Apache and
lighttpd.

This also matches the behaviour of the "share" action in Unit.

This doesn't effect the behaviour of the 'script' option which bypasses
the nxt_php_dynamic_request() function.

This also adds a couple of tests to test/test_php_application.py to
ensure this continues to work.

Closes: <https://github.com/nginx/unit/issues/717>
Closes: <https://github.com/nginx/unit/issues/753>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2229:3a230013e58a27-Oct-2022 Andrew Clayton

Fixed some function definitions.

Future releases of GCC will render function definitions like

func()

invalid by default. See the previous commit 09f88c9 ("Fixed main()
prototypes in auto tests."

Fixed some function definitions.

Future releases of GCC will render function definitions like

func()

invalid by default. See the previous commit 09f88c9 ("Fixed main()
prototypes in auto tests.") for details.

Such functions should be defined like

func(void)

This is a good thing to do regardless of the upcoming GCC changes.

Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

2224:478701bc670618-Nov-2021 Remi Collet

TLS: Using ERR_get_error_all() with OpenSSL 3.

Link: <https://www.openssl.org/docs/man3.0/man7/migration_guide.html>
Cc: Andy Postnikov <apostnikov@gmail.com>
Cc: Andrew Clayton <a.clayton@nginx.com

TLS: Using ERR_get_error_all() with OpenSSL 3.

Link: <https://www.openssl.org/docs/man3.0/man7/migration_guide.html>
Cc: Andy Postnikov <apostnikov@gmail.com>
Cc: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Remi Collet <remi@remirepo.net>
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2223:1019031754fe16-Jan-2019 Remi Collet

Preferring system crypto policy.

If we don't call SSL_CTX_set_cipher_list(), then it uses the
system's default.

Link: <https://fedoraproject.org/wiki/Changes/CryptoPolicy>
Link: <https://docs.fedor

Preferring system crypto policy.

If we don't call SSL_CTX_set_cipher_list(), then it uses the
system's default.

Link: <https://fedoraproject.org/wiki/Changes/CryptoPolicy>
Link: <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/>
Link: <https://www.redhat.com/en/blog/consistent-security-crypto-policies-red-hat-enterprise-linux-8>
Signed-off-by: Remi Collet <remi@remirepo.net>
Acked-by: Andrei Belov <defan@nginx.com>
[ alx: add changelog and tweak commit message ]
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2220:b57b4749b99314-Oct-2022 Zhidao HONG

Configuration: stopped automatic migration to the "share" behavior.

This commit removed the $uri auto-append for the "share" option
introduced in rev be6409cdb028.

The main reason is that it causes

Configuration: stopped automatic migration to the "share" behavior.

This commit removed the $uri auto-append for the "share" option
introduced in rev be6409cdb028.

The main reason is that it causes problems when preparing Unit configurations
to be loaded at startup from the state directory. E.g. Docker. A valid conf.json
file with $uri references will end up with $uri$uri due to the auto-append.

show more ...

2219:b3c156896c7c13-Oct-2022 Remi Collet

Added parentheses for consistency.

Reported-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Remi Collet <remi@remirepo.net>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: A

Added parentheses for consistency.

Reported-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Remi Collet <remi@remirepo.net>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2218:ed81ed291d0b02-Jun-2022 Remi Collet

PHP: Fixed php_module_startup() call for PHP 8.2.

PHP 8.2 changed the prototype of the function, removing the last
parameter.

Signed-off-by: Remi Collet <remi@remirepo.net>
Cc: Timo Stark <t.stark@

PHP: Fixed php_module_startup() call for PHP 8.2.

PHP 8.2 changed the prototype of the function, removing the last
parameter.

Signed-off-by: Remi Collet <remi@remirepo.net>
Cc: Timo Stark <t.stark@nginx.com>
Cc: George Peter Banyard <girgias@php.net>
Tested-by: Andy Postnikov <apostnikov@gmail.com>
Acked-by: Andy Postnikov <apostnikov@gmail.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>

show more ...

2217:8019e6c650f610-Sep-2022 Alex Colomar

Added missing error checking in the C API.

pthread_mutex_init(3) may fail for several reasons, and failing to
check will cause Undefined Behavior when those errors happen. Add
missing checks, and c

Added missing error checking in the C API.

pthread_mutex_init(3) may fail for several reasons, and failing to
check will cause Undefined Behavior when those errors happen. Add
missing checks, and correctly deinitialize previously created
stuff before exiting from the API.

Signed-off-by: Alejandro Colomar <alx@nginx.com>
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Reviewed-by: Zhidao HONG <z.hong@f5.com>

show more ...

2216:231b36f0062c06-Oct-2022 Andrew Clayton

Fixed the build on MacOS (and others).

@alejandro-colomar reported that the build was broken on MacOS

cc -o build/unitd -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -W

Fixed the build on MacOS (and others).

@alejandro-colomar reported that the build was broken on MacOS

cc -o build/unitd -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -fstrict-aliasing -Wstrict-overflow=5 -Wmissing-prototypes -Werror -g \
build/src/nxt_main.o build/libnxt.a \
\
\
-L/usr/local/Cellar/pcre2/10.40/lib -lpcre2-8
Undefined symbols for architecture x86_64:
"_nxt_fs_mkdir_parent", referenced from:
_nxt_runtime_pid_file_create in libnxt.a(nxt_runtime.o)
_nxt_runtime_controller_socket in libnxt.a(nxt_controller.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [build/unitd] Error 1

This was due to commit 57fc920 ("Socket: Created control socket & pid file
directories.").

This happened because this commit introduced the usage of
nxt_fs_mkdir_parent() in core code which uses nxt_fs_mkdir(), both of
these are defined in src/nxt_fs.c. It turns out however that this file
doesn't get built on MacOS (or any system that isn't Linux or that
lacks a FreeBSD compatible nmount(2) system call) due to the following

In auto/sources we have

if [ $NXT_HAVE_ROOTFS = YES ]; then
NXT_LIB_SRCS="$NXT_LIB_SRCS src/nxt_fs.c"
fi

NXT_HAVE_ROOTFS is set in auto/isolation

If [ $NXT_HAVE_MOUNT = YES -a $NXT_HAVE_UNMOUNT = YES ]; then
NXT_HAVE_ROOTFS=YES

cat << END >> $NXT_AUTO_CONFIG_H
#ifndef NXT_HAVE_ISOLATION_ROOTFS
#define NXT_HAVE_ISOLATION_ROOTFS 1
#endif
END

fi

While we do have a check for a generic umount(2) which is found on
MacOS, for mount(2) we currently only check for the Linux mount(2) and
FreeBSD nmount(2) system calls. So NXT_HAVE_ROOTFS is set to NO on MacOS
and we don't build src/nxt_fs.c

This fixes the immediate build issue by taking the mount/umount OS
support out of nxt_fs.c into a new nxt_fs_mount.c file which is guarded
by the above while we now build nxt_fs.c unconditionally.

This should fix the build on any _supported_ system.

Reported-by: Alejandro Colomar <alx@nginx.com>
Fixes: 57fc920 ("Socket: Created control socket & pid file directories.")
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

show more ...

12345678910>>...55