Ich habe auf meinem Raspberry Pi PHP auf Version 7.3.11 geupgradet und dann die hier empfohlenen Anpassungen in /etc/nginx/sites-enabled/default vorgenommen. Seither ist meine Nextcloud 17 mausetot. Ein Reboot des Rechners hat daran nichts geändert.
Wie kann ich den Fehler finden und beheben?
Wie bei jeder Fehlersuche ist es hilfreich einen Blick in die Logdateien zu werfen. Da Du Anpassungen an den nginx-Einstellungen vorgenommen hast würde ich dort beginnen 
Ist das das richtige Logile?
/var/log/nginx/error.log
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: bind() to [::]:80 failed (98: Address already in use)
2019/10/30 11:08:16 [emerg] 661#661: still could not bind()Ja, dies ist die richtige Datei, welche eindeutig das Problem ausweist: "bind () to 0.0.0.0:80 failed (98: Address already in use)". Stelle sicher, dass ein Zugriff auf Port 80/tcp nicht mehrfach in der Konfiguration existiert.
Ohje. Das überfordert meine beschränkten Kenntnisse.
Muss ich dazu in /etc/nginx/sites-enabled/default etwas ändern? Die Datei hat derzeit folgenden Inhalt:
upstream php-handler {
#server 127.0.0.1:9000;
server unix:/var/run/php/php7.3-fpm.sock;
}
server {
listen 80;
listen [::]:80;
server_name v_______d.f_______y.com;
# enforce https
#return 301 https://$server_name$request_uri;
root /var/www/html/;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name v_______d.f_______y.com;
ssl_certificate /etc/letsencrypt/live/v_______d.f_______y.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vv_______d.f_______y.com/privkey.pem;
# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
# Path to the root of your installation
root /var/www/html/;
# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this
# topic first.
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
# Path to the root of your installation
root /var/www/html/;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
# last;
location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+$
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
location / {
rewrite ^ /index.php;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
fastcgi_split_path_info ^(.+\.php)(/.*)$;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
#Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff|svg|gif)$ {
try_files $uri /index.php$uri$is_args$args;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
# Optional: Don't log access to assets
access_log off;
}
location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
try_files $uri /index.php$uri$is_args$args;
# Optional: Don't log access to other assets
access_log off;
}
}Ich selbst nutze zwar kein Nginx, würde aber sagen dass Du die genannte Zeile einmal auskommentieren solltest. Bitte auch direkt die weiter unten aufgeführte Zeile mit dem Port 443 auskommentieren und danach den Server neu starten.
Bringt nichts. NC bleibt tot. Im Logfile hat sich (fast) nichts verändert:
2019/10/30 16:07:57 [emerg] 672#672: bind() to 0.0.0.0:80 failed (98: Address already in use)
2019/10/30 16:07:57 [emerg] 672#672: still could not bind()Bitte vor einem neuen Startversuch unbedingt prüfen, ob nicht ein anderer Dienst bereits auf Port 80/tcp hört: netstat -alpn | grep ":80"
Falls wirklich kein anderer Dienst läuft muss es eine weitere, fehlerhafte Konfigurationszeile gebe. Was findest Du denn in Zeile 98 Deiner Konfiguration?
Eventuell gibt es auch eine weitere Konfigurationdatei in welcher versucht wird Port 80/tcp zu belegen. grep ":80" /etc/nginx/sites-enabled/*
sudo netstat -alpn | grep ":80"
tcp6 0 0 :::80 :::* LISTEN 673/apache2Interpretiere ich das richtig? Bei mir läuft außer nginx noch ein Apache, der ebenfalls auf den Port 80 zugreift. Aber warum läuft da plötzlich ein Apache herum, der vor dem PHP-Update nicht aktiv war?
Oder ist meine Interpretation falsch?
So sieht es scheinbar aus. Beende doch einmal den apache2 Webserver und versuche dann Nginx zu starten. Falls dies klappt kannst Du im Anschluss ja wieder mit den zuvor auskommentierten Einträgen experimentieren
NextCloudPi v1.18.0 released
Wird denn bitte NextCloudPi verwendet oder aber stattdessen nur eine andere Standardumgebung von Linux auf einem Pi-Rechner?
Es tut mir leid, von diesem sicherlich ärgerlichen Fehlerumstand zu hören. Und natürlich mag ich mich irren. Leider kann ich, auch mangels eigener Erfahrung mit dem tatsächlichen Umgang bei Nextcloud auf Pi-Rechnern, auch nicht wirklich groß helfen.
Zu beachten ist allerdings (und bei Nachlesen der oben von mir angeführten Dokumente auch vielleicht nachvollziehbar) daß man anscheinend gehörig aufpassen muss, um nicht ärgerlichen Missverständnissen zum Opfer zu werden:
apt-Kommando) ohne kritische Prüfung (und wenn ob überhaupt) verwenden. NextCloudPi hat dazu ganz offensichtlich zwei besondere Befehle ncp-update und ncp-dist-upgrade, die man unbedingt nutzen sollte, damit die speziellen Anforderung für Pi-Rechner überhaupt erst erfüllt werden können.Soweit dazu.
Zur allgemeinen Beachtung:
Bei anderen Installierungen (z.B. Debian, Ubuntu, ArchLinux etc.) und bei (wie auch immer) entstandenen abweichenden (z.B. “selbstgestrickten” ?) Konfigurierungen ist ohne Frage mit den beschriebenen Problemen durch NGINX zu rechnen und müssen diese auch zielführend gelöst werden.
Sorry for your mishap.
Hope this helps.
Nein. Meine Konfiguration beschrieb ich im Ausgangspost. Im Prinzip bin ich nach dieser Anleitung vorgegangen.
Ich habe jetzt mal mutig den Apachen gestoppt.
sudo systemctl stop apache2.serviceUnd dann nginx gestartet.
sudo systemctl restart nginx.serviceJetzt läuft meine Nextcloud wieder.
Wo und wie kann ich herausfinden, wer den Apachen gestartet hatte und für die Zukunft verhindern, dass das wieder passiert?
Nun ja, nicht so ganz vollständig leider.
Wie war das oben noch geschrieben?
Da fehlte wohl noch so einiges an Information, daher ja auch meine vorsichtige Frage. Abw es macht ja nix, nur in Zukunft bitte vielleicht etwas mehr auf die technischen Details achten.
Übrigens könnte die NC Issue Template App vielleicht helfen, etwas mehr Informationen anzugeben, wenn man mal etwas mehr Hilfe bei Nextcloud braucht. In diesem Fall natürlich völlig zwecklos, weil NC ja “tot” war.
@vatolin Na das hört sich doch gut an. Gratuliere.
NB Eine kleine Geste der Zufriedenheit als ein “dieser Beitrag gefällt mir” (mit einem Klick auf das Herz 
am unteren Rand) bei einem oder mehreren meiner obigen Beiträge würde mich freuen. Der Applaus wäre (nicht nur aber auch für mich) ein schöner Dank und schon genug Motivation für künftige ähnliche Hilfestellungen…
Der Apache-Webserver gehört zum Standardrepertoire von Debian und wird meistens gleich mit installiert, wenn man nicht von Anfang an streng auf eine Mininimalaustatttung setzt. Zum “wer” einfach mal in den Spiegel schauen? Zum “wie” würde ich mir keine großen Gedanken machen, ist halt mal passiert.
Die apt-Paketverwaltung hilft üblicher Weise weiter.
Mit apt list apache2* nach den entsprechenden Paketen aus dem Apache-Umfeld schauen. Es werden mehr Pakete angezeigt, als tatsächlich installiert sind. Die wirklich installierten Pakete aber haben ein [installiert … ] bzw. [installed …] am Zeilenende in der erzeugten Liste stehen.
Danach mit apt remove apache2 (also ohne ‘*’) den Hauptteil wegräumen, damit es nicht irrtümlich nochmals von vorne los geht. Nochmals mit apt list apache2* nachschauen und sofern noch etwas übrig geblieben sein sollte, diese weiteren Pakete dann einzeln mit dem entsprechenden Namen und vorangestelltem apt remove ... löschen.
Mit apt purge apache2 kann man die Reste gründlich auskehren, muss man aber nicht.
Viel Glück!
Oha. Da hast Du in der Tat recht. Hab ich vor Schreck, dass die Cloud offline war, glatt vergessen.
Danke für die zielführende Hilfestellung.