Puncte:0

Vechiul site WordPress cu stivă LEMP nu se va mai implementa

drapel tz

Am moștenit un site WordPress 5.7 care rulează pe o picătură Ubuntu 16.04.3 x64, care utilizează o bază de date separată MySQL 8 gestionată de DigitalOcean.

Site-ul WordPress este un site de stivă Trellis LEMP. PHP versiunea 7.3, dar Nginx pare să folosească 7.1 dintr-un phpinfo().

Sunt conștient că toate versiunile sunt foarte depășite și au nevoie de actualizare, dar în termen foarte imediat trebuie să fac lucrurile să funcționeze.

A apărut o eroare de conectare la baza de date (vezi https://www.digitalocean.com/community/questions/since-a-wordpress-url-change-i-can-t-connect-to-do-managed-mysql-database) și asta m-a implicat să încerc o mulțime de lucruri neînțelepte până acum, implementarea pe site-ul de realizare prin Trellis eșuează.

Iată ce scrie:

SARCINA [implementare: Reîncărcați php-fpm] **************************************************** ************************************* Informații despre sistem: Ansible 2.7.0; Linux Trellis la „Comutați de la .dev la .Test" --------------------------------------------- - fatal: [staging.mywebsite.co.uk]: FAILED! => {"schimbat": adevărat, "cmd": "sudo service php7.3-fpm reload", "delta": "0:00:00.030313", "end": „2021-12-21 11:51:06.490541”, „msg”: „cod de returnare diferit de zero”, „rc”: 1, „start”: „2021-12-21 11:51:06.460228”, „stderr”: „php7.3-fpm.service nu este activ, nu se poate reîncărca.", "stderr_lines": ["php7.3-fpm.service nu este activ, nu se poate reîncărca."], "stdout": "", "stdout_lines": []} la reîncercați, utilizați: --limit @/home/ubuntu/mywebsite.co.uk/trellis/deploy.retry

Dacă intru SSH și încerc să pornesc serviciul, primesc

Lucrarea pentru php7.3-fpm.service a eșuat deoarece procesul de control a ieșit cu cod de eroare. Vezi „systemctl status php7.3-fpm.service” și „journalctl -xe” pentru detalii.

Iată starea systemctl php7.3-fpm.service:

â php7.3-fpm.service - Managerul de procese PHP 7.3 FastCGI
   Încărcat: încărcat (/lib/systemd/system/php7.3-fpm.service; activat; prestabilit furnizor: activat)
   Activ: eșuat (Rezultat: cod de ieșire) din marți 21.12.2021 12:04:49 GMT; acum 47 de minute
     Documente: man:php-fpm7.3(8)
  Proces: 1658 ExecStart=/usr/sbin/php-fpm7.3 --nodaemonize --fpm-config /etc/php/7.3/fpm/php-fpm.conf (code=exited, st
 PID principal: 1658 (cod=ieșit, stare=78)

21 decembrie 12:04:49 ubuntu-xxx-xxx-01 systemd[1]: Pornirea Managerului de procese PHP 7.3 FastCGI...
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 php-fpm7.3[1658]: [21-Dec-2021 12:04:49] EROARE: O altă instanță FPM pare să fie deja
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 php-fpm7.3[1658]: [21-Dec-2021 12:04:49] EROARE: inițializarea FPM a eșuat
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 systemd[1]: php7.3-fpm.service: Procesul principal a fost ieșit, cod=ieșit, stare=78/n/a
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 systemd[1]: Nu s-a pornit Managerul de procese PHP 7.3 FastCGI.
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 systemd[1]: php7.3-fpm.service: Unitatea a intrat în stare eșuată.
21 decembrie 12:04:49 ubuntu-xxx-xxx-01 systemd[1]: php7.3-fpm.service: a eșuat cu rezultatul „exit-code”.

Și journalctl -xe:

-- Suport: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unitatea sesiunea-9.scope s-a terminat de pornire.
--
-- Rezultatul de pornire este gata.
21 dec 12:53:07 ubuntu-xxx-xxx-01 sshd[1915]: Deconectare primită de la portul 92.0.0.0 53386:11: La revedere [preauth]
21 decembrie 12:53:07 ubuntu-xxx-xxx-01 sshd[1915]: deconectat de la portul 92.0.0.0 53386 [preauth]
Dec 21 12:55:34 ubuntu-xxx-xxx-01 sudo[1919]: root : TTY=pts/0 ; PWD=/rădăcină; UTILIZATOR=rădăcină ; COMMAND=/bin/systemctl sta
21 decembrie 12:55:34 ubuntu-xxx-xxx-01 sudo[1919]: pam_unix(sudo:session): sesiune deschisă pentru utilizator root de către root(uid=0)
21 decembrie 12:55:34 ubuntu-xxx-xxx-01 systemd[1]: Pornirea Managerului de procese PHP 7.3 FastCGI...
-- Subiect: Unitatea php7.3-fpm.service a început pornirea
-- Definit de: systemd
-- Suport: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unitatea php7.3-fpm.service a început să pornească.
Dec 21 12:55:34 ubuntu-xxx-xxx-01 php-fpm7.3[1922]: [21-Dec-2021 12:55:34] EROARE: O altă instanță FPM pare să fie deja
21 decembrie 12:55:34 ubuntu-xxx-xxx-01 php-fpm7.3[1922]: [21-Dec-2021 12:55:34] EROARE: inițializarea FPM a eșuat
21 decembrie 12:55:34 ubuntu-xxx-xxx-01 systemd[1]: php7.3-fpm.service: Procesul principal a fost ieșit, cod=ieșit, stare=78/n/a
21 decembrie 12:55:34 ubuntu-xxx-xxx-01 systemd[1]: Nu s-a pornit Managerul de procese PHP 7.3 FastCGI.
-- Subiect: Unitatea php7.3-fpm.service a eșuat
-- Definit de: systemd
-- Suport: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unitatea php7.3-fpm.service a eșuat.
--
-- Rezultatul a eșuat.

Și sunt blocat. Nu sunt foarte încrezător într-un mediu Linux, așa că sunt complet pierdut să fiu sincer. Cred că trebuie să repar asta înainte de a remedia eroarea de conectare la baza de date!

Am încercat să adaug PHP 7.4, dar acest lucru a generat câteva pagini de erori roșii când am încercat să implementez site-ul, așa că l-am eliminat.

Acesta este un site de organizare, deci nu este esențial, dar, evident, site-ul de producție are aceeași configurație de fundal pentru că sunt îngrozit să se rupă și eu!

Pe termen lung, intenționez să actualizez totul, dar aș dori foarte mult ajutor pentru a încerca să funcționeze imediat pe termen scurt.

Mulțumiri!

drapel cn
Ați încercat următoarele: „Consultați „systemctl status php7.3-fpm.service” și „journalctl -xe” pentru detalii”.
drapel tz
Am editat pentru a adăuga aceste informații :)
Puncte:2
drapel cn

Spune clar că php-fpm7.3 nu reușește să înceapă pentru că EROARE: O altă instanță FPM pare să fie deja. Probabil că ai php-fpm7.1 deja fuge.

drapel tz
Da tocmai am vazut asta! Orice idee despre cum pot afla asta și, ei bine, oprește-l și rulează-l pe celălalt :)
drapel cn
`systemctl status php7.1-fpm.service`
drapel tz
A lucrat! S-a remediat și eroarea de conectare la DB! S-a oprit 7.1 și a început 7.3. Pf! Mulțumesc mult.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.