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 ...

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 ...

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 ...

Fixing isolated process PID manipulation.

Registering an isolated PID in the global PID hash is wrong
because it can be duplicated. Isolated processes are stored only
in the children list until the

Fixing isolated process PID manipulation.

Registering an isolated PID in the global PID hash is wrong
because it can be duplicated. Isolated processes are stored only
in the children list until the response for the WHOAMI message is
processed and the global PID is discovered.

To remove isolated siblings, a pointer to the children list is
introduced in the nxt_process_init_t struct.

This closes #633 issue on GitHub.

show more ...

Merged with the 1.26 branch.

Fixing prototype process crash.

A prototype stores linked application processes structures. When an
application process terminates, it's removed from the list. To avoid double
removal, the pointer

Fixing prototype process crash.

A prototype stores linked application processes structures. When an
application process terminates, it's removed from the list. To avoid double
removal, the pointer to the next element should be set to NULL.

The issue was introduced in c8790d2a89bb.

show more ...

Sending shared port to application prototype.

Application process started with shared port (and queue) already configured.
But still waits for PORT_ACK message from router to start request processin

Sending shared port to application prototype.

Application process started with shared port (and queue) already configured.
But still waits for PORT_ACK message from router to start request processing
(so-called "ready state").

Waiting for router confirmation is necessary. Otherwise, the application may
produce response and send it to router before the router have the information
about the application process. This is a subject of further optimizations.

show more ...

Introducing application prototype processes.

Improved logging of app module load errors.

Moving request limit control to libunit.

Introducting application graceful stop. For now only used when application
process reach request limit value.

This closes #585 issue on GitHub.

Isolation: mounting of procfs by default when using "rootfs".

Preserving the app port write socket.

The socket is required for intercontextual communication in multithreaded apps.

Moved isolation related code to "nxt_isolation.c".

Moving file descriptor blocking to libunit.

The default libunit behavior relies on blocking the recv() call for port file
descriptors, which an application may override if needed. For external
appl

Moving file descriptor blocking to libunit.

The default libunit behavior relies on blocking the recv() call for port file
descriptors, which an application may override if needed. For external
applications, port file descriptors were toggled to blocking mode before the
exec() call. If the exec() call failed, descriptor remained blocked, so the
process hanged while trying to read from it.

This patch moves file descriptor mode switch inside libunit.

show more ...

Libunit refactoring: port management.

- Changed the port management callbacks to notifications, which e. g. avoids
the need to call the libunit function
- Added context and library instance referenc

Libunit refactoring: port management.

- Changed the port management callbacks to notifications, which e. g. avoids
the need to call the libunit function
- Added context and library instance reference counts for a safer resource
release
- Added the router main port initialization

show more ...

Fixing main and application port structs file descriptor init.

Correct value for non-initialized file descriptor is -1, because most of the
checks in libunit compares file descriptor with -1 before

Fixing main and application port structs file descriptor init.

Correct value for non-initialized file descriptor is -1, because most of the
checks in libunit compares file descriptor with -1 before performing an
action. Using 0 as default value, may cause to close file descriptor #0, this
may affect application logic.

It is not required to list this patch in changelog because impact is not seen
by end users.

show more ...

Fixing buffer overflow check in discovery.

Incorrect check prevents Unit to start without modules.

This issue was introduced in 4a3ec07f4b19.

Isolation: fixed build when features aren't detected.

Added "rootfs" feature.

Refactor of process management.

The process abstraction has changed to:

setup(task, process)
start(task, process_data)
prefork(task, process, mp)

The prefork() occurs in the main process rig

Refactor of process management.

The process abstraction has changed to:

setup(task, process)
start(task, process_data)
prefork(task, process, mp)

The prefork() occurs in the main process right before fork.

The file src/nxt_main_process.c is completely free of process
specific logic.

The creation of a process now supports a PROCESS_CREATED state. The
The setup() function of each process can set its state to either
created or ready. If created, a MSG_PROCESS_CREATED is sent to main
process, where external setup can be done (required for rootfs under
container).

The core processes (discovery, controller and router) doesn't need
external setup, then they all proceeds to their start() function
straight away.

In the case of applications, the load of the module happens at the
process setup() time and The module's init() function has changed
to be the start() of the process.

The module API has changed to:

setup(task, process, conf)
start(task, data)

As a direct benefit of the PROCESS_CREATED message, the clone(2) of
processes using pid namespaces now doesn't need to create a pipe
to make the child block until parent setup uid/gid mappings nor it
needs to receive the child pid.

show more ...

Fixing process crash in case of module load error.

This is related to #330 issue on GitHub.

Exiting application process in case of pre_init stage error.

Removed unnecessary abstraction layer.

Introducing Java Servlet Container beta.

Renamed "go" application type to "external".

There's nothing specific to Go language. This type of application object can
be used to run any external application that utilizes libunit API.