# Μετά την ενημέρωση: επανεκκίνηση του PHP-FPM και όλων των workers

> Επανεκκίνηση PHP-FPM μετά την ενημέρωση του PHP2Shell: γιατί δεν αρκούν τα νέα αρχεία, ποιες υπηρεσίες μετρούν και πώς ελέγχετε ότι δεν εκτελείται παλιός worker.

Πηγή: https://phpsos.de/el/php2shell/php-fpm-neustart/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

**Εν συντομία:** Μετά την ενημέρωση της PHP πρέπει να επανεκκινήσετε το PHP-FPM και όλες τις άλλες υπηρεσίες που φορτώνουν PHP. Τα νέα αρχεία στον δίσκο δεν αρκούν, όσο παλιές διεργασίες PHP εκτελούνται στη μνήμη. Μόνο μετά την επανεκκίνηση εργάζεται ο διακομιστής με τον διορθωμένο κώδικα των PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ή του backport του παρόχου σας.

## Γιατί πρέπει να επανεκκινήσετε το PHP-FPM

Μια ενημέρωση πακέτων αντικαθιστά τα αρχεία στον δίσκο. Οι διεργασίες που εκτελούνται ήδη έχουν όμως φορτώσει στη μνήμη τον παλιό κώδικα του προγράμματος και συνεχίζουν να εργάζονται με αυτόν. Το PHP-FPM, ο Apache με mod_php ή το LiteSpeed κρατούν τους workers τους συχνά ζωντανούς για ημέρες.

Για το PHP2Shell αυτό είναι ιδιαίτερα σημαντικό. Η ευπάθεια [CVE-2026-109619](https://phpsos.de/el/php2shell/cve-2026-109619/) εξαρτάται ακριβώς από κατάσταση που παραμένει ανάμεσα στα αιτήματα στον ίδιο worker. Ένας worker με παλιό κώδικα παραμένει ευάλωτος, όποια έκδοση κι αν βρίσκεται στον δίσκο. Σύμφωνα με το php.net πρέπει γι' αυτό να επανεκκινηθούν όλοι οι workers και οι διεργασίες.

Ορισμένοι διαχειριστές πακέτων επανεκκινούν αυτόματα τις υπηρεσίες κατά την ενημέρωση, άλλοι όχι. Μην βασίζεστε σε αυτό, αλλά ελέγξτε το αποτέλεσμα.

Μια τυπική εικόνα της καθημερινότητας: η διαχείριση πακέτων αναφέρει «PHP ενημερώθηκε», η παρακολούθηση δεν δείχνει σφάλματα, ο ιστότοπος λειτουργεί. Παρ' όλα αυτά οι παλιοί workers εξακολουθούν να εξυπηρετούν κάθε αίτημα, επειδή κανείς δεν επανεκκίνησε την υπηρεσία. Απ' έξω αυτή η κατάσταση δεν αναγνωρίζεται. Γι' αυτό ο έλεγχος των χρόνων εκκίνησης των διεργασιών ανήκει σε κάθε ενημέρωση.

## Ποιες υπηρεσίες φορτώνουν PHP;

| Τρόπος λειτουργίας | Τι να επανεκκινήσετε | Τυπική εντολή (τα ονόματα διαφέρουν ανά διανομή) |
|---|---|---|
| PHP-FPM | κάθε υπηρεσία FPM, ανά εγκατεστημένη έκδοση | `systemctl restart php8.3-fpm` ή `systemctl restart php-fpm` |
| Apache με mod_php | Apache | `systemctl restart apache2` ή `systemctl restart httpd` |
| php-cgi | τον διακομιστή ιστού που το καλεί ή το wrapper FastCGI | ανάλογα με τη διαμόρφωση |
| LiteSpeed | το LiteSpeed και τις διεργασίες lsphp | μέσω της διαχείρισης του LiteSpeed ή της υπηρεσίας του |
| FrankenPHP | την υπηρεσία FrankenPHP ή το container | `systemctl restart frankenphp` ή δημιουργία νέου container |
| Docker, Kubernetes | δημιουργία containers από νέο image | βλ. [Patch της PHP σε containers Docker](https://phpsos.de/el/php2shell/docker-container-patchen/) |

Στο mod_php ισχύει: η ενημέρωση αφορά τον ίδιο τον Apache, επειδή η PHP βρίσκεται σε κάθε διεργασία του Apache. Γιατί αυτός ο τρόπος λειτουργίας είναι ιδιαίτερα ευαίσθητος, αναφέρεται στο [Γιατί το mod_php φέρει τον υψηλότερο κίνδυνο](https://phpsos.de/el/php2shell/mod-php-risiko/). Για το LiteSpeed θα βρείτε λεπτομέρειες στη σελίδα [LiteSpeed και LSAPI](https://phpsos.de/el/server/litespeed/).

## Επανεκκίνηση του PHP-FPM: οι εντολές

Πρώτα εντοπίστε όλες τις υπηρεσίες PHP στον διακομιστή. Το Plesk, το cPanel και άλλες διεπαφές φέρνουν δικές τους υπηρεσίες PHP με δικά τους ονόματα· η λίστα τις εμφανίζει επίσης.

```bash
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
```

Στη συνέχεια επανεκκινήστε κάθε υπηρεσία PHP που βρέθηκε, όχι μόνο την πρώτη:

```bash
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm      # αν είναι εγκατεστημένος δεύτερος κλάδος
sudo systemctl restart apache2         # για mod_php· οικογένεια RHEL: httpd
```

Συνιστούμε `restart` αντί για `reload`. Στο reload η κύρια διεργασία παραμένει· προορίζεται για αλλαγές διαμόρφωσης. Μετά από μια ενημέρωση ασφαλείας θέλετε να είστε βέβαιοι ότι κάθε διεργασία είναι νέα.

> **Σημαντικό:**
> Αν έχετε ορίσει επιπλέον προσωρινά μέτρα, όπως `session.upload_progress.enabled=0` ή σταθερά όρια μνήμης, ισχύουν και αυτά μόνο μετά την επανεκκίνηση. Μια επανεκκίνηση τα κάνει και τα δύο σε ένα βήμα.

## Έλεγχος ότι δεν εκτελείται πλέον παλιός worker

Συγκρίνετε την ώρα εκκίνησης των διεργασιών με τη χρονική στιγμή της ενημέρωσης. Όλες οι εντολές είναι αποκλειστικά ανάγνωσης.

```bash
ps -o pid,lstart,cmd -C php-fpm8.3     # unter RHEL: -C php-fpm
systemctl status php8.3-fpm            # γραμμή «Active: … since …»
needrestart -r l                       # Debian/Ubuntu, αν είναι εγκατεστημένο
```

Αν μια διεργασία είναι παλαιότερη από την ενημέρωση, δεν συμπεριλήφθηκε. Συχνές αιτίες είναι ένας ξεχασμένος δεύτερος κλάδος PHP, μια ξεχωριστή υπηρεσία pool από πίνακα ελέγχου φιλοξενίας ή ένα container που επανεκκινήθηκε αντί να δημιουργηθεί από το νέο image. Το αν εκτελείται η σωστή έκδοση, δείχνει η σελίδα [Σωστός έλεγχος έκδοσης PHP και επιπέδου patch](https://phpsos.de/el/php2shell/php-version-pruefen/).

## Τεκμηρίωση της επανεκκίνησης

Σημειώστε για κάθε διακομιστή τη χρονική στιγμή της ενημέρωσης και της επανεκκίνησης. Αυτή η στιγμή διαχωρίζει το διάστημα που ο διακομιστής ήταν ευάλωτος από το διάστημα μετά. Για έναν μεταγενέστερο έλεγχο ιχνών, για ασφαλιστικές εταιρείες και για μια ενδεχόμενη γνωστοποίηση βάσει ΓΚΠΔ είναι το σημαντικότερο σημείο αναφοράς. Φυλάξτε επιπλέον τα logs του διακομιστή από τις 20 Οκτωβρίου, όπως συνιστά ο ειδικός τύπος.

Σε διακομιστές με πολλούς ιστοτόπους αξίζει ένας σύντομος πίνακας: διακομιστής, υπηρεσία, έκδοση PHP, έκδοση πακέτου, χρονική στιγμή της επανεκκίνησης και το πρόσωπο που έκανε την επανεκκίνηση. Έτσι τα κενά στην κάλυψη γίνονται γρήγορα αντιληπτά, για παράδειγμα ένα pool που παραβλέφθηκε ή ένα σύστημα δοκιμών που κανείς δεν είχε στη λίστα.

## Πώς βοηθά συγκεκριμένα η PHP SOS;

Στο πλαίσιο της [υπηρεσίας PHP patch](https://phpsos.de/el/leistungen/php-patch-service/) αναλαμβάνουμε την ενημέρωση και την επανεκκίνηση ως ενιαία διαδικασία:

- **Εντοπισμός υπηρεσιών:** Βρίσκουμε όλες τις διεργασίες που φορτώνουν PHP, ακόμη και από πίνακες ελέγχου φιλοξενίας και containers.
- **Ελεγχόμενη επανεκκίνηση,** κατόπιν συνεννόησης μαζί σας σε κατάλληλη στιγμή και με προσοχή σε παραγγελίες ή φόρμες που βρίσκονται σε εξέλιξη.
- **Μεταγενέστερος έλεγχος** ότι καμία διεργασία δεν είναι παλαιότερη από την ενημέρωση και ότι ο ιστότοπος ανταποκρίνεται κανονικά.
- **Καταγραφή:** εκδόσεις, επίπεδα πακέτων και χρόνοι επανεκκίνησης ανά διακομιστή.


## Συχνές ερωτήσεις

**Αρκεί το systemctl reload αντί για restart;**  
Για το PHP2Shell συνιστούμε restart. Ένα reload επανεκκινεί μεν συνήθως τους workers, η κύρια διεργασία όμως μπορεί να συνεχίσει να εκτελείται. Με το restart βεβαιώνεστε ότι δεν μένει καμία διεργασία με παλιό κώδικα. Απέναντι στη σύντομη διακοπή βρίσκεται μια σαφής απόδειξη.

**Πρέπει μετά την ενημέρωση PHP να επανεκκινήσω ολόκληρο τον διακομιστή;**  
Κατά κανόνα όχι. Αρκεί να επανεκκινηθούν όλες οι υπηρεσίες που φορτώνουν PHP: PHP-FPM, Apache στο mod_php, LiteSpeed, FrankenPHP ή τα επηρεαζόμενα containers. Η επανεκκίνηση ολόκληρου του διακομιστή είναι η απλή παραλλαγή, όταν δεν είστε βέβαιοι ποιες υπηρεσίες χρησιμοποιούν PHP.

**Επανεκκινεί ο πάροχος φιλοξενίας μου αυτόματα την PHP μετά την ενημέρωση;**  
Αυτό εξαρτάται από τον πάροχο. Ρωτήστε συγκεκριμένα αν μετά το patch επανεκκινήθηκαν όλες οι διεργασίες PHP και ζητήστε γραπτή επιβεβαίωση.

## Πηγές

- [php.net: Ανακοινώσεις ασφαλείας](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)