Revision tags: 1.32.0-1, 1.32.0 |
|
#
2686:87259ed41698 |
| 05-Feb-2024 |
Andrew Clayton |
Wasm-wc: Wire up the language module to the config system
This exposes the various WebAssembly Component Model language module specific options.
The application type is "wasm-wasi-component".
Ther
Wasm-wc: Wire up the language module to the config system
This exposes the various WebAssembly Component Model language module specific options.
The application type is "wasm-wasi-component".
There is a "component" option that is required, this specifies the full path to the WebAssembly component to be run. This component should be in binary format, i.e a .wasm file.
There is also currently one optional option
"access"
Due to the sandboxed nature of WebAssembly, by default Wasm modules/components don't have any access to the underlying filesystem.
There is however a capabilities based mechanism[0] for allowing such access.
This adds a config option to the 'wasm-wasi-component' application type (same as for 'wasm'); 'access.filesystem' which takes an array of directory paths that are then made available to the wasm module/component. This access works recursively, i.e everything under a specific path is allowed access to.
Example config might look like
"applications": { "my-wasm-component": { "type": "wasm-wasi-component", "component": "/path/to/component.wasm", "access" { "filesystem": [ "/tmp", "/var/tmp" ] } } }
The actual mechanism used allows directories to be mapped differently in the guest. But at the moment we don't support that and just map say /tmp to /tmp. This can be revisited if it's something users clamour for.
[0]: <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2635:e693d3895f1f |
| 08-Feb-2024 |
Alejandro Colomar |
Configuration: Fix validation of "processes"
It's an integer, not a floating number.
Fixes: 68c6b67ffc84 ("Configuration: support for rational numbers.") Closes: https://github.com/nginx/unit/issue
Configuration: Fix validation of "processes"
It's an integer, not a floating number.
Fixes: 68c6b67ffc84 ("Configuration: support for rational numbers.") Closes: https://github.com/nginx/unit/issues/1115 Link: <https://github.com/nginx/unit/pull/1116> Reviewed-by: Zhidao Hong <z.hong@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Cc: Dan Callahan <d.callahan@f5.com> Cc: Valentin Bartenev <vbartenev@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
show more ...
|
#
2634:dbbb8d750e4e |
| 31-Jan-2024 |
Alejandro Colomar |
Configuration: Don't corrupt abstract socket names
The commit that added support for Unix sockets accepts abstract sockets using '@' in the config, but we stored it internally using '\0'.
We want t
Configuration: Don't corrupt abstract socket names
The commit that added support for Unix sockets accepts abstract sockets using '@' in the config, but we stored it internally using '\0'.
We want to support abstract sockets transparently to the user, so that if the user configures unitd with '@', if we receive a query about the current configuration, the user should see the same exact thing that was configured. So, this commit avoids the transformation in the internal state file, storing user input pristine, and we only transform the '@' in temporary strings.
This commit fixes another bug, where we try to connect to abstract sockets with a trailing '\0' in their name due to calling twice nxt_sockaddr_parse() on the same string. By calling that function only once with each copy of the string, we have fixed that bug.
The following code was responsible for this bug, which the second time it was called, considered these sockets as file-backed (not abstract) Unix socket, and so appended a '\0' to the socket name.
$ grepc -tfd nxt_sockaddr_unix_parse . | grep -A10 @ if (path[0] == '@') { path[0] = '\0'; socklen--; #if !(NXT_LINUX) nxt_thread_log_error(NXT_LOG_ERR, "abstract unix domain sockets are not supported"); return NULL; #endif }
sa = nxt_sockaddr_alloc(mp, socklen, addr->length);
This bug was found thanks to some experiment about using 'const' for some strings.
And here's some history:
- 9041d276fc6a ("nxt_sockaddr_parse() introducted.")
This commit introduced support for abstract Unix sockets, but they only worked as "servers", and not as "listeners". We corrupted the JSON config file, and stored a \u0000. This also caused calling connect(2) with a bogus trailing null byte, which tried to connect to a different abstract socket.
- d8e0768a5bae ("Fixed support for abstract Unix sockets.")
This commit (partially) fixed support for abstract Unix sockets, so they they worked also as listeners. We still corrupted the JSON config file, and stored a \u0000. This caused calling connect(2) (and now bind(2) too) with a bogus trailing null byte.
- e2aec6686a4d ("Storing abstract sockets with @ internally.")
This commit fixed the problem by which we were corrupting the config file, but only for "listeners", not for "servers". (It also fixes the issue about the terminating '\0'.) We completely forgot about "servers", and other callers of the same function.
To reproduce the problem, I used the following config:
```json { "listeners": { "*:80": { "pass": "routes/u" }, "unix:@abstract": { "pass": "routes/a" } },
"routes": { "u": [{ "action": { "pass": "upstreams/u" } }], "a": [{ "action": { "return": 302, "location": "/i/am/not/at/home/" } }] },
"upstreams": { "u": { "servers": { "unix:@abstract": {} } } } } ```
And then check the state file:
$ sudo cat /opt/local/nginx/unit/master/var/lib/unit/conf.json \ | jq . \ | grep unix; "unix:@abstract": { "unix:\u0000abstract": {}
After this patch, the state file has a '@' as expected:
$ sudo cat /opt/local/nginx/unit/unix/var/lib/unit/conf.json \ | jq . \ | grep unix; "unix:@abstract": { "unix:@abstract": {}
Regarding the trailing null byte, here are some tests:
$ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/d8e0/sbin/unitd \ |& grep abstract; [pid 22406] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = 0 [pid 22410] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = 0 ^C $ sudo killall unitd $ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/master/sbin/unitd \ |& grep abstract; [pid 22449] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0 [pid 22453] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract\0"}, 12) = -1 ECONNREFUSED (Connection refused) ^C $ sudo killall unitd $ sudo strace -f -e 'bind,connect' /opt/local/nginx/unit/unix/sbin/unitd \ |& grep abstract; [pid 22488] bind(10, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0 [pid 22492] connect(134, {sa_family=AF_UNIX, sun_path=@"abstract"}, 11) = 0 ^C
Fixes: 9041d276fc6a ("nxt_sockaddr_parse() introducted.") Fixes: d8e0768a5bae ("Fixed support for abstract Unix sockets.") Fixes: e2aec6686a4d ("Storing abstract sockets with @ internally.") Link: <https://github.com/nginx/unit/pull/1108> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Cc: Liam Crilly <liam.crilly@nginx.com> Cc: Zhidao Hong <z.hong@f5.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
show more ...
|
#
2631:9f1accbed182 |
| 24-Jan-2024 |
Andrew Clayton |
Configuration: Remove procmap validation code
With the previous commit which introduced the use of the NXT_CONF_VLDT_REQUIRED flag, we no longer need to do this separate validation, it's only purpos
Configuration: Remove procmap validation code
With the previous commit which introduced the use of the NXT_CONF_VLDT_REQUIRED flag, we no longer need to do this separate validation, it's only purpose was to check if the three uidmap/gidmap settings had been provided.
Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2630:cd51408f14a2 |
| 24-Jan-2024 |
Andrew Clayton |
Configuration: Use the NXT_CONF_VLDT_REQUIRED flag for procmap
Use the NXT_CONF_VLDT_REQUIRED flag on the app_procmap members. These three settings are required.
These are for the uidmap & gidmap s
Configuration: Use the NXT_CONF_VLDT_REQUIRED flag for procmap
Use the NXT_CONF_VLDT_REQUIRED flag on the app_procmap members. These three settings are required.
These are for the uidmap & gidmap settings in the config.
Suggested-by: Zhidao HONG <z.hong@f5.com> Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2625:a6b688c5757c |
| 23-Jan-2024 |
Zhidao HONG |
HTTP: enhanced access log with conditional filtering.
This feature allows users to specify conditions to control if access log should be recorded. The "if" option supports a string and JavaScript co
HTTP: enhanced access log with conditional filtering.
This feature allows users to specify conditions to control if access log should be recorded. The "if" option supports a string and JavaScript code. If its value is empty, 0, false, null, or undefined, the logs will not be recorded. And the '!' as a prefix inverses the condition.
Example 1: Only log requests that sent a session cookie.
{ "access_log": { "if": "$cookie_session", "path": "..." } }
Example 2: Do not log health check requests.
{ "access_log": { "if": "`${uri == '/health' ? false : true}`", "path": "..." } }
Example 3: Only log requests when the time is before 22:00.
{ "access_log": { "if": "`${new Date().getHours() < 22}`", "path": "..." } }
or
{ "access_log": { "if": "!`${new Date().getHours() >= 22}`", "path": "..." } }
Closes: https://github.com/nginx/unit/issues/594
show more ...
|
#
2610:5bc9788b05ec |
| 11-Dec-2023 |
Zhidao HONG |
HTTP: added TSTR validation flag to the rewrite option.
This is to improve error messages for rewrite configuration. Take the configuration as an example:
{ "rewrite": "`${a + " }
Previo
HTTP: added TSTR validation flag to the rewrite option.
This is to improve error messages for rewrite configuration. Take the configuration as an example:
{ "rewrite": "`${a + " }
Previously, when applying it the user would see this error message:
failed to apply previous configuration
After this change, the user will see this improved error message:
the previous configuration is invalid: "SyntaxError: Unexpected end of input in default:1" in the "rewrite" value.
show more ...
|
Revision tags: 1.31.1-1, 1.31.1, 1.31.0-1, 1.31.0 |
|
#
2519:285dfc5bd459 |
| 09-Aug-2023 |
Andrew Clayton |
Wasm: Add support for directory access.
Due to the sandboxed nature of WebAssembly, by default WASM modules don't have any access to the underlying filesystem.
There is however a capabilities based
Wasm: Add support for directory access.
Due to the sandboxed nature of WebAssembly, by default WASM modules don't have any access to the underlying filesystem.
There is however a capabilities based mechanism[0] for allowing such access.
This adds a config option to the 'wasm' application type; 'access.filesystem' which takes an array of directory paths that are then made available to the WASM module. This access works recursively, i.e everything under a specific path is allowed access to.
Example config might look like
"access" { "filesystem": [ "/tmp", "/var/tmp" ] }
The actual mechanism used allows directories to be mapped differently in the guest. But at the moment we don't support that and just map say /tmp to /tmp. This can be revisited if it's something users clamour for.
Network sockets are another resource that may be controlled in this manner, for example there is a wasi_config_preopen_socket() function, however this requires the runtime to open the network socket then effectively pass this through to the guest.
This is something that can be revisited in the future if users desire it.
[0]: <https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2518:b2f9d61b2799 |
| 09-Aug-2023 |
Andrew Clayton |
Wasm: Wire up Wasm language module support to the config system.
This exposes various WebAssembly language module specific options.
The application type is "wasm".
There is a "module" option that
Wasm: Wire up Wasm language module support to the config system.
This exposes various WebAssembly language module specific options.
The application type is "wasm".
There is a "module" option that is required, this specifies the full path to the WebAssembly module to be run. This module should be in binary format, i.e a .wasm file.
There are also currently eight function handlers that can be specified. Three of them are _required_
1) request_handler
The main driving function. This may be called multiple times for a single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This memory is allocated from the WASM modules address space and is what is sued for communicating between the WASM module (the guest) and Unit (the host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following five _optional_ handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent all its headers and data.
Example config
"applications": { "luw-echo-request": { "type": "wasm", "module": "/path/to/unit-wasm/examples/c/luw-echo-request.wasm", "request_handler": "luw_request_handler", "malloc_handler": "luw_malloc_handler", "free_handler": "luw_free_handler", "module_init_handler": "luw_module_init_handler", "module_end_handler": "luw_module_end_handler", } }
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2512:5e9e70378c1d |
| 09-Aug-2023 |
Zhidao HONG |
HTTP: controlling response headers support.
|
Revision tags: 1.30.0-1, 1.30.0 |
|
#
2450:14277f21a722 |
| 08-May-2023 |
Zhidao HONG |
NJS: supported loadable modules.
|
#
2448:243735980417 |
| 20-Apr-2023 |
Zhidao HONG |
HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from th
HTTP: added basic URI rewrite.
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ]
Reviewed-by: Alejandro Colomar <alx@nginx.com>
show more ...
|
#
2437:8973f763920b |
| 18-Mar-2023 |
Andrew Clayton |
Allow to remove the version string in HTTP responses.
Normally Unit responds to HTTP requests by including a header like
Server: Unit/1.30.0
however it can sometimes be beneficial to withhold th
Allow to remove the version string in HTTP responses.
Normally Unit responds to HTTP requests by including a header like
Server: Unit/1.30.0
however it can sometimes be beneficial to withhold the version information and in this case just respond with
Server: Unit
This patch adds a new "settings.http" boolean option called server_version, which defaults to true, in which case the full version information is sent. However this can be set to false, e.g
"settings": { "http": { "server_version": false } },
in which case Unit responds without the version information as the latter example above shows.
Link: <https://www.ietf.org/rfc/rfc9110.html#section-10.2.4> Closes: <https://github.com/nginx/unit/issues/158> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2426:d5e936f09dc0 |
| 30-Mar-2023 |
Andrew Clayton |
Add per-application logging.
Currently when running in the foreground, unit application processes will send stdout to the current TTY and stderr to the unit log file.
That behaviour won't change.
Add per-application logging.
Currently when running in the foreground, unit application processes will send stdout to the current TTY and stderr to the unit log file.
That behaviour won't change.
When running as a daemon, unit application processes will send stdout to /dev/null and stderr to the unit log file.
This commit allows to alter the latter case of unit running as a daemon, by allowing applications to redirect stdout and/or stderr to specific log files. This is done via two new application options, 'stdout' & 'stderr', e.g
"applications": { "myapp": { ... "stdout": "/path/to/log/unit/app/stdout.log", "stderr": "/path/to/log/unit/app/stderr.log" } }
These log files are created by the application processes themselves and thus the log directories need to be writable by the user (and or group) of the application processes.
E.g
$ sudo mkdir -p /path/to/log/unit/app $ sudo chown APP_USER /path/to/log/unit/app
These need to be setup before starting unit with the above config.
Currently these log files do not participate in log-file rotation (SIGUSR1), that may change in a future commit. In the meantime these logs can be rotated using the traditional copy/truncate method.
NOTE:
You may or may not see stuff printed to stdout as stdout was traditionally used by CGI applications to communicate with the webserver.
Closes: <https://github.com/nginx/unit/issues/197> Closes: <https://github.com/nginx/unit/issues/846> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2381:a68b5f5bf46c |
| 26-Jan-2023 |
Alejandro Colomar |
HTTP: added route logging.
- Configuration: added "/config/settings/http/log_route".
Type: bool Default: false
This adds configurability to the error log. It allows enabling and disa
HTTP: added route logging.
- Configuration: added "/config/settings/http/log_route".
Type: bool Default: false
This adds configurability to the error log. It allows enabling and disabling logs related to how the router performs selection of the routes.
- HTTP: logging request line.
Log level: [notice]
The request line is essential to understand which logs correspond to which request when reading the logs.
- HTTP: logging route that's been discarded.
Log level: [info]
- HTTP: logging route whose action is selected.
Log level: [notice]
- HTTP: logging when "fallback" action is taken.
Log level: [notice]
Closes: <https://github.com/nginx/unit/issues/758> Link: <https://github.com/nginx/unit/pull/824> Link: <https://github.com/nginx/unit/pull/839> Suggested-by: Timo Stark <t.stark@nginx.com> Suggested-by: Mark L Wood-Patrick <mwoodpatrick@gmail.com> Suggested-by: Liam Crilly <liam@nginx.com> Tested-by: Liam Crilly <liam@nginx.com> Acked-by: Artem Konev <a.konev@f5.com> Cc: Andrew Clayton <a.clayton@nginx.com> Cc: Andrei Zeliankou <zelenkov@nginx.com> Reviewed-by: Zhidao Hong <z.hong@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
show more ...
|
Revision tags: 1.29.1-1, 1.29.1 |
|
#
2345:5c9cb7e205d3 |
| 30-Jan-2023 |
Zhidao HONG |
NJS: adding the missing vm destruction.
This commit fixed the njs memory leak happened in the config validation, updating and http requests.
|
#
2318:6f198d76ee62 |
| 30-Jan-2023 |
Zhidao HONG |
NJS: adding the missing vm destruction.
This commit fixed the njs memory leak happened in the config validation, updating and http requests.
|
Revision tags: 1.29.0-1, 1.29.0 |
|
#
2273:a13c26f62477 |
| 14-Nov-2021 |
OutOfFocus4 |
Python: Added "prefix" to configuration.
This patch gives users the option to set a `"prefix"` attribute for Python applications, either at the top level or for specific `"target"`s. If the attribut
Python: Added "prefix" to configuration.
This patch gives users the option to set a `"prefix"` attribute for Python applications, either at the top level or for specific `"target"`s. If the attribute is present, the value of `"prefix"` must be a string beginning with `"/"`. If the value of the `"prefix"` attribute is longer than 1 character and ends in `"/"`, the trailing `"/"` is stripped.
The purpose of the `"prefix"` attribute is to set the `SCRIPT_NAME` context value for WSGI applications and the `root_path` context value for ASGI applications, allowing applications to properly route requests regardless of the path that the server uses to expose the application.
The context value is only set if the request's URL path begins with the value of the `"prefix"` attribute. In all other cases, the `SCRIPT_NAME` or `root_path` values are not set. In addition, for WSGI applications, the value of `"prefix"` will be stripped from the beginning of the request's URL path before it is sent to the application.
Reviewed-by: Andrei Zeliankou <zelenkov@nginx.com> Reviewed-by: Artem Konev <artem.konev@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
show more ...
|
#
2266:3f66d6e064e2 |
| 06-Dec-2022 |
Andrew Clayton |
Configuration: made large_header_buffers a valid setting.
This is an extension to the previous commit, which made large_header_buffer_size a valid configuration setting.
This commit makes a related
Configuration: made large_header_buffers a valid setting.
This is an extension to the previous commit, which made large_header_buffer_size a valid configuration setting.
This commit makes a related value, large_header_buffers, a valid configuration setting.
While large_header_buffer_size effectively limits the maximum size of any single header (although unit will try to pack multiple headers into a buffer if they wholly fit).
large_header_buffers limits how many of these 'large' buffers are available. It makes sense to also allow this to be user set.
large_header_buffers is already set by the configuration system in nxt_router.c it just isn't set as a valid config option in nxt_conf_validation.c
With this change users can set this option in their config if required by the following
"settings": { "http": { "large_header_buffers": 8 } },
It retains its default value of 4 if this is not set.
NOTE: This is being released as undocumented and subject to change as it exposes internal workings of unit.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2265:6c65127da239 |
| 04-May-2022 |
Andrew Clayton |
Configuration: made large_header_buffer_size a valid setting.
@JanMikes and @tagur87 on GitHub both reported issues with long URLs that were exceeding the 8192 byte large_header_buffer_size setting,
Configuration: made large_header_buffer_size a valid setting.
@JanMikes and @tagur87 on GitHub both reported issues with long URLs that were exceeding the 8192 byte large_header_buffer_size setting, which resulted in a HTTP 431 error (Request Header Fields Too Large).
This can be resolved in the code by updating the following line in src/nxt_router.c::nxt_router_conf_create()
skcf->large_header_buffer_size = 8192;
However, requiring users to modify unit and install custom versions is less than ideal. We could increase the value, but to what?
This commit takes the option of allowing the user to set this option in their config by making large_header_buffer_size a valid configuration setting.
large_header_buffer_size is already set by the configuration system in nxt_router.c it just isn't set as a valid config option in nxt_conf_validation.c
With this change users can set this option in their config if required by the following
"settings": { "http": { "large_header_buffer_size": 16384 } },
It retains its default value of 8192 bytes if this is not set.
With this commit, without the above setting or too low a value, with a long URL you get a 431 error. With the above setting set to a large enough value, the request is successful.
NOTE: This setting really determines the maximum size of any single header _value_. Also, unit will try and place multiple values into a buffer _if_ they fully fit.
NOTE: This is being released as undocumented and subject to change as it exposes internal workings of unit.
Closes: <https://github.com/nginx/unit/issues/521> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
show more ...
|
#
2262:0bca3af03c75 |
| 24-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 ...
|
#
2247:baa6b9879267 |
| 20-Nov-2022 |
Zhidao HONG |
Basic njs support.
|
#
2246:5f4056478375 |
| 20-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 ...
|
#
2232:1fb2182a4d03 |
| 02-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 ...
|
#
2220:b57b4749b993 |
| 14-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 ...
|