Lighttpd

I always recommend spawning your backends manually (and using a different user to run them); in the past spawn-fcgi was the right tool, but with systemd you can also use Systemd.

Especially with systemd you can easily run multiple services (e.g. with systemd templates) for the same socket, and pass them any identifier you want (for example this redmine instance runs on two backends based on one socket).

Thank you for the answer! We do not have the systemd. We use systemv. Is there an example available on how to use spawn-fcgi?

If you can't find examples in the spawn-fcgi wiki I linked you haven't been looking. debian (and probably others) also provides nicely rendered online man pages: https://manpages.debian.org/spawn-fcgi

Whether you can get multiple backends on a single socket working depends on your "service supervisor" (if you even have one at all - but I strongly recommend to get one. runit, daemontools, ... - although I don't think anything but systemd supports multiple backends on a single socket).

I think multiple sockets (and backend spawnings with different parameters, if you really need to) should work too - you just need to configure those explicitly in lighttpd.

Thank you kindly for the answer - a second look did indeed reveal the desired examples for the use of spawn-fcgi!
The last point you mention: "backend spawnings with different parameters, if you really need to) should work too - you just need to configure those explicitly in lighttpd" was indeed what we have been trying all along - but did not succeed in. I dare again to ask for a link or example - hoping I did not miss a hint!

I think it should look like this:

fastcgi.server = (
  <extension> => (
    ( "socket" => ..., otheroptions backend1... ),
    ( "socket" => ..., otheroptions backend2... ),
  ),
)

@rod: mod_fastcgi documentation has options for starting FastCGI backends from lighttpd.

Hint: we've had to point you at the documentation multiple times. I recommend trying to read more carefully, reading more than once, and then trying things out. If you still have trouble understanding the documentation, please ask a more specific question that demonstrates you have read the documentation and tried some things out yourself.

What have you tried?

to be specific: i tried to enable the backend process to identify itself. For this i tried to use bin-environment in order to give the backend process it's number: Doing "socket" => "/tmp/restapi.socket" creates the sockets: /tmp/restapi.socket-0, /tmp/restapi.socket-1 and /tmp/restapi.socket-2. What I want is to give e.g. the "0" to the process with the "/tmp/restapi.socket-0". i tried the below - but do not know what to use for "backendprocessnr" in order to get the above "0" into the environment of the respective process.

fastcgi.server = (
  # all requests prefixed with '/' are forwarded to the FastCGI backend
    "/" => (
        "restapi.handler" => (
            "socket" => "/tmp/restapi.socket",
            "bin-path" => "/usr/bin/restapi",
      "bin-environment" => ( 
       "IDENTIFIER" => "backendprocessnr" 
     ),
            "max-procs" => 3,
      "check-local" => "disable",
        )
    )
)

as an alternative tried:

fastcgi.server = (
  # all requests prefixed with '/' are forwarded to the FastCGI backend
    "/" => (
        "restapi.handler" => (
            ("socket" => "/tmp/restapi.socket1","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "1"),"max-procs" => 1,"check-local" => "disable"),
            ("socket" => "/tmp/restapi.socket2","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "2"),"max-procs" => 1,"check-local" => "disable"),
            ("socket" => "/tmp/restapi.socket3","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "3"),"max-procs" => 1,"check-local" => "disable"),
    )
)
)

daemon.err lighttpd[30850]: (../../lighttpd-1.4.55/src/gw_backend.c.1261) unexpected value for gw.server near [restapi.handler](string); expected ( "ext" => ( "backend-label" => ( "key" => "value" )))

Instead of "restapi.handler" with "max-procs" => 3, try defining "restapi.handler-1", "restapi.handler-2", "restapi.handler-3", etc, each with "max-procs" => 1, and each with its own unique "socket" and own unique "IDENTIFIER"

You may define only one "socket" per "restapi.handler-x"

For other that may read this: spawn-fcgi should still be preferred for better isolation of the application servers.

BTW, I haven't tried this, but it might be possible to getsockname() on stdin in the FastCGI application startup and to obtain the identifier by parsing the "/tmp/restapi.socket-x" path produced by lighttpd when there are multiple "max-procs"

What is the need for the identifiers? Why not use the process pid of each backend? Or fstat() the socket on stdin and use the inode?

first:

fastcgi.server = (
  # all requests prefixed with '/' are forwarded to the FastCGI backend
    "/" => ("restapi.handler-1" => ("socket" => "/tmp/restapi.socket-1","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "1"),"max-procs" => 1,"check-local" => "disable"),
            "restapi.handler-2" => ("socket" => "/tmp/restapi.socket-2","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "2"),"max-procs" => 1,"check-local" => "disable"),
            "restapi.handler-3" => ("socket" => "/tmp/restapi.socket-3","bin-path" => "/usr/bin/restapi","bin-environment" => ( "IDENTIFIER" => "3"),"max-procs" => 1,"check-local" => "disable"),
    )
)

worked as you proposed (y) thank you for the great support!!!

second: using the pid is what we used in the meantime - but: whenever a process is killed ungracefully, a socket path remains in the file system - over the time this litters the system and on a small embedded device can cause problems.

third: as a workaround I did check the pid of the child process, went to /proc/<pid>/fd got the inode of the socket to lighttpd and then identified the respective child by using the inode to map it in /proc/net/unix to the socket path. The alternative that you propose sounds promising as well! But giving the identifier directly via the lighttpd to it's children seems way more direct!

Concerning: "spawn-fcgi should still be preferred for better isolation of the application servers." is something I would like dig into a bit - also for the sake of people reading this entry who also are currently using the inbuild functionality: At a first glance it sounds tempting to use the lighttpd functionality as to my experience it reliably starts and restarts the child processes even after ungraceful terminations. Are there known issues with the spawning/respawning? Security shortcomings? What are the major drivers for the proposed isolation?

ok ok ok - I heard you guys:

Privilege separation without needing a suid-binary or running a server as root.
Protect (unix) socket - only the webserver can connect to your backend (especially php can be vulnerable if untrusted users can connect)
You can restart your web server and the FastCGI applications without restarting the others.
You can run them in different chroot()s.
Running your FastCGI applications doesn’t depend on the web server you are running, which allows for easier testing of/migration to other web servers.