Andrew Clayton c1299faa7d Isolation: Switch to fork(2) & unshare(2) on Linux.
On GitHub, @razvanphp & @hbernaciak both reported issues running the
APCu PHP module under Unit.

When using this module they were seeing errors like

  'apcu_fetch(): Failed to acquire read lock'

However when running APCu under php-fpm, everything was fine.

The issue turned out to be due to our use of SYS_clone breaking the
pthreads(7) API used by APCu.  Even if we had been using glibc's
clone(2) wrapper we would still have run into problems due to a known
issue there.

Essentially the problem is when using clone, glibc doesn't update the
TID cache, so the child ends up having the same TID as the parent and
that is used in various parts of pthreads(7) such as in the various
locking primitives, so when APCu was grabbing a lock it ended up using
the TID of the main unit process (rather than that of the php
application processes that was grabbing the lock).

So due to the above what was happening was when one of the application
processes went to grab either a read or write lock, the lock was
actually being attributed to the main unit process.  If a process had
acquired the write lock, then if a process tried to acquire a read or
write lock then glibc would return EDEADLK due to detecting a deadlock
situation due to thinking the process already held the write lock when
in fact it didn't.

It seems the right way to do this is via fork(2) and unshare(2).  We
already use fork(2) on other platforms.

This requires a few tricks to keep the essence of the processes the same
as before when using clone

  1) We use the prctl(2) PR_SET_CHILD_SUBREAPER option (if its
     available, since Linux 3.4) to make the main unit process inherit
     prototype processes after a double fork(2), rather than them being
     reparented to 'init'.

     This avoids needing to ^C twice to fully exit unit when running in
     the foreground.  It's probably also better if they maintain their
     parent child relationship where possible.

  2) We use a double fork(2) technique on the prototype processes to
     ensure they themselves end up in a new PID namespace as PID 1 (when
     CLONE_NEWPID is being used).

     When using unshare(CLONE_NEWPID), the calling process is _not_
     placed in the namespace (as discussed in pid_namespaces(7)).  It
     only sets things up so that subsequent children are placed in a PID
     namespace.

     Having the prototype processes as PID 1 in the new PID namespace is
     probably a good thing and matches the behaviour of clone(2).  Also,
     some isolation tests break if the prototype process is not PID 1.

  3) Due to the above double fork(2) the main unit process looses track
     of the prototype process ID, which it needs to know.

     To solve this, we employ a simple pipe(2) between the main unit and
     prototype processes and pass the prototype grandchild PID from the
     parent of the second fork(2) before exiting.  This needs to be done
     from the parent and not the grandchild, as the grandchild will see
     itself having a PID of 1 while the main process needs its
     externally visible PID.

Link: <https://www.php.net/manual/en/book.apcu.php>
Link: <https://sourceware.org/bugzilla/show_bug.cgi?id=21793>
Closes: <https://github.com/nginx/unit/issues/694>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2022-11-18 23:53:30 +00:00
2022-01-10 16:07:31 +03:00
2022-05-03 12:41:36 +02:00
2020-09-18 19:37:56 +01:00
2022-09-13 09:30:30 +01:00
2022-10-03 14:16:44 +01:00
2022-12-15 12:32:46 +00:00
2017-09-06 18:26:37 +03:00
2022-02-15 18:21:10 +03:00
2022-11-24 15:06:54 +00:00
2023-02-27 19:13:56 +00:00

NGINX Unit

Universal Web App Server

NGINX Unit Logo

NGINX Unit is a lightweight and versatile open-source server that has three core capabilities:

  • it is an HTTP reverse proxy,
  • a web server for static media assets,
  • and an application server that runs code in seven languages.

We are building a universal tool that compresses several layers of the modern application stack into a potent, coherent solution with a focus on performance, low latency, and scalability. It is intended as a building block for any web architecture regardless of its complexity, from enterprise-scale deployments to your pet's homepage.

Unit's native RESTful JSON API enables dynamic updates with zero interruptions and flexible configuration, while its out-of-the-box productivity reliably scales to production-grade workloads. We achieve that with a complex, asynchronous, multithreading architecture comprising multiple processes to ensure security and robustness while getting the most out of today's computing platforms.

Quick Installation

macOS

$ brew install nginx/unit/unit

For details and available language packages, see the docs.

Docker

$ docker pull docker.io/nginx/unit

For a description of image tags, see the docs.

Amazon Linux, Fedora, RedHat

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && yum install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Debian, Ubuntu

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && apt install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Running a Hello World App

Suppose you saved a PHP script as /www/helloworld/index.php:

<?php echo "Hello, PHP on Unit!"; ?>

To run it on Unit with the unit-php module installed, first set up an application object. Let's store our first config snippet in a file called config.json:

{
    "helloworld": {
        "type": "php",
        "root": "/www/helloworld/"
    }
}

Saving it as a file isn't necessary, but can come in handy with larger objects.

Now, PUT it into the /config/applications section of Unit's control API, usually available by default via a Unix domain socket:

# curl -X PUT --data-binary @config.json --unix-socket  \
       /path/to/control.unit.sock http://localhost/config/applications

{
	"success": "Reconfiguration done."
}

Next, reference the app from a listener object in the /config/listeners section of the API. This time, we pass the config snippet straight from the command line:

# curl -X PUT -d '{"127.0.0.1:8000": {"pass": "applications/helloworld"}}'  \
       --unix-socket /path/to/control.unit.sock http://localhost/config/listeners
{
    "success": "Reconfiguration done."
}

Now Unit accepts requests at the specified IP and port, passing them to the application process. Your app works!

$ curl 127.0.0.1:8080

      Hello, PHP on Unit!

Finally, query the entire /config section of the control API:

# curl --unix-socket /path/to/control.unit.sock http://localhost/config/

Unit's output should contain both snippets, neatly organized:

{
    "listeners": {
        "127.0.0.1:8080": {
            "pass": "applications/helloworld"
        }
    },

    "applications": {
        "helloworld": {
            "type": "php",
            "root": "/www/helloworld/"
        }
    }
}

For full details of configuration management, see the docs.

Community

  • The go-to place to start asking questions and share your thoughts is our Slack channel.

  • Our GitHub issues page offers space for a more technical discussion at your own pace.

  • The project map on GitHub sheds some light on our current work and plans for the future.

  • Our official website may provide answers not easily found otherwise.

  • Get involved with the project by contributing! See the contributing guide for details.

  • To reach the team directly, subscribe to the mailing list.

  • For security issues, email us, mentioning NGINX Unit in the subject and following the CVSS v3.1 spec.

Description
No description provided
Readme 12 MiB
Languages
Shell 63.7%
HTML 36.3%