Plugin claims that it works, but doesn't write anything.

Hi Xaymar, please don’t use the reviews section for support request. It’s not really fair to blame a plugin when your upstream php host does not seem to be configured correctly.

This plugin does not create or write any files. It creates feeds. If you see an empty page, it might mean that the stylesheet (for human readability of the XML source) is not passed correctly which does not hinder your sitemap from being read by search engines.

If you need help, please create a thread on the support forum.

…that would mean that I’d get an error message

That’s exactly what you said in your second post:

…the error log for fastcgi says that there was no response from the upstream host(PHP).

How did I misread that?

Also, even Google Webmaster Tools was unable to read the sitemap, so yeah. Not working, in the slightest.

Like I said, create a thread on https://wordpress.org/support/plugin/xml-sitemap-feed or at least provide a link to your sitemap so it can be studied live if you want help.

OK, let’s ignore all www subdomain and subdirectory URLs there because http://project-kube.de/www/ and http://www.project-kube.de/ return 404 WordPress pages too (why do you not 301 redirect www to non-www?) and concentrate on the working http://project-kube.de/?feed=sitemap … this shows the sitemap feed is there and it’s functional.

Now the pretty permalink: http://project-kube.de/sitemap.xml

This shows an Nginx 404 repsonse which indicates Nginx does not pass the request to index.php … but to let WordPress handle a request for this URL, it MUST be passed to index.php

I advise at least following the General Rules on https://codex.wordpress.org/Nginx where it is important to have:

location / {
	try_files $uri $uri/ /index.php?$args;
}

and make sure you do NOT have xml in the regexp match rule

# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
       access_log off; log_not_found off; expires max;
}

But I can really recommend following https://rtcamp.com/wordpress-nginx/tutorials/ which if you decide to start using easyengine is the absolute top in easy Nginx server management 🙂

Edit: As soon as I put it back into the chroot, it just stops working again. PHP, nginx, MySql are all up to date from sources.

Are all public files (in /var/www/wherever) chown’d to www-data:www-data and do you have in your PHP’s http://www.conf the following?

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Also make sure that if you install plugins via (S)FTP, the user and group are www-data too…

What PHP commands get blacklisted? And what is doing this blacklisting?

I have a custom built setup that is designed to serve content as fast as possible from multiple other servers and itself.

A separate DB server? If so, then just set up the MySQL (or MariaDB) service and connection first and easyengine will detect it, consider it installed and not touch it further.
A CDN for static media files? Why not add W3TC or Super Cache and you can set everything up via the WP back-end.

EasyEngine is not a panel. It’s a command line script that automates many tasks and has defaults for very fast, WordPress optimized setings. But yeah, it’s not for managing a cluster of servers.

pcntl_alarm,pcntl_fork, pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsigna
led,pcntl_wexitstatus, pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error, pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec, pcntl_getpriority,pcntl_setpriority

Those are all PCNTL functions http://php.net/manual/en/ref.pcntl.php but this plugin does not use any of those. I see no reason why that blacklist would interfere with plugin operations.

What’s your PHP memory limit and how many posts does your site have?

Well, it does not sound like a memory issue. And when accessed over the non-pretty URLs the feeds render just fine:
http://project-kube.de/?feed=sitemap-posttype-page
http://project-kube.de/?feed=sitemap-posttype-post

The only problem I see is that Nginx does not pass pretty URL requests that end with .xml to index.php … And it seems a /robots.txt request does not get passed to index.php either which is too bad because WordPress can render a valid robots.txt response too.

Hi Brian, a simple

location / {
  try_files $uri $uri/ /index.php?$args;
}

should take care of everything including sitemap-news.xml and your dynamic (WP generated) robots.txt 🙂