Avviare, riavviare e fermare Apache e MySQL su Ubuntu

Controllare il servizio prima di toccarlo

Su Ubuntu, Apache e MySQL sono quasi sempre gestiti da systemd. Questo cambia il modo di operare rispetto ai vecchi comandi di init: non si lavora più sul processo in modo diretto, ma sul servizio, cioè sull’unità che systemd monitora, avvia e riavvia. In pratica, quando devi avviare, fermare o riavviare uno dei due, la prima domanda non è “qual è il comando?”, ma “il servizio è davvero installato, abilitato e in stato coerente?”.

La regola utile in produzione è semplice: prima osservi, poi cambi. Un restart sparato a caso può mascherare il problema per qualche secondo e lasciarti senza traccia della causa. Per Apache questo significa controllare lo stato dell’unità e i log del demone HTTP; per MySQL significa verificare se il server è attivo, se il socket esiste, se la porta 3306 è in ascolto e se il motore ha scritto errori di avvio o di crash recovery.

Avvio, arresto e riavvio con systemd

I comandi base sono questi. Sono volutamente identici per Apache e MySQL, cambia solo il nome del servizio. Su Ubuntu i nomi più comuni sono apache2 e mysql. In alcune installazioni MySQL può essere sostituito da MariaDB, con unità come mariadb: il principio resta lo stesso, ma il nome del servizio va verificato.

1. Avviare Apache:

sudo systemctl start apache2

2. Riavviare Apache:

sudo systemctl restart apache2

3. Fermare Apache:

sudo systemctl stop apache2

4. Avviare MySQL:

sudo systemctl start mysql

5. Riavviare MySQL:

sudo systemctl restart mysql

6. Fermare MySQL:

sudo systemctl stop mysql

Se vuoi un controllo rapido dopo il comando, usa sempre lo stato del servizio:

systemctl status apache2 --no-pager
systemctl status mysql --no-pager

Lo stato atteso è active (running) quando il servizio deve essere online, oppure inactive (dead) quando lo hai fermato volutamente. Se vedi failed, non sei davanti a un semplice “servizio spento”: c’è stato un errore di avvio o un crash da indagare.

Capire cosa sta succedendo davvero

Il comando systemctl status ti dà il primo quadro, ma per una diagnosi seria servono i log. Su Ubuntu, per Apache i dettagli sono spesso in /var/log/apache2/error.log; per MySQL il percorso può variare in base alla versione e alla configurazione, ma in molti casi trovi informazioni utili tramite journalctl prima ancora di andare a cercare file specifici.

Un ciclo di verifica ragionevole è questo:

1. Controlla lo stato dell’unità con systemctl status.
2. Leggi gli ultimi eventi del journal con journalctl -u nome-servizio -n 50 --no-pager.
3. Se Apache è il problema, guarda /var/log/apache2/error.log.
4. Se MySQL è il problema, cerca errori di socket, permessi, InnoDB o spazio disco.

Esempi pratici:

sudo journalctl -u apache2 -n 50 --no-pager
sudo journalctl -u mysql -n 50 --no-pager
sudo tail -n 50 /var/log/apache2/error.log

Se il servizio non parte, i sintomi più frequenti sono abbastanza prevedibili. Apache può fallire per una direttiva errata in una virtual host, un modulo mancante o una porta già occupata. MySQL può fallire per un database corrotto, un problema di permessi sui file dati, un disco pieno, un socket non creato o una configurazione invalida in /etc/mysql/mysql.conf.d/.

Gestire Apache senza perdere il controllo del sito

Apache è il front-end HTTP. Quando lo riavvii, stai impattando direttamente la disponibilità del sito. Su un server di produzione il riavvio è in genere breve, ma non va trattato come un’operazione innocua: se hai molte connessioni attive, il cambio di processo può chiudere richieste in corso o interrompere upload e sessioni lunghe.

Se devi fare manutenzione, la sequenza corretta è: verifica la configurazione, applica il cambio, poi riavvia o ricarica. Per Apache, quando la modifica riguarda solo configurazioni che supportano il reload, puoi spesso evitare il restart completo. In altri casi il riavvio è inevitabile. Prima di toccare il servizio, conviene validare la sintassi:

sudo apache2ctl configtest

Se il risultato è Syntax OK, hai almeno escluso gli errori di parsing più banali. Se invece trovi un errore, il comando di avvio o riavvio fallirà spesso nello stesso punto, e il log di Apache ti dirà quale file e quale riga correggere.

Per una verifica post-avvio, controlla che il servizio ascolti sulle porte previste:

sudo ss -ltnp | grep -E ':(80|443)\b'

Se non compare nulla, non basta che systemctl dica “active”: potrebbe esserci un’unità attiva ma non agganciata alle porte giuste, oppure Apache potrebbe essere partito senza riuscire a bindare l’interfaccia. In quel caso il journal mostra quasi sempre il motivo reale.

Gestire MySQL con un occhio ai dati

MySQL richiede più cautela di Apache perché non stai solo gestendo un processo, ma un motore che mantiene stato e dati su disco. Un semplice stop è di solito sicuro, ma un restart su un server con I/O saturo, filesystem pieno o errori InnoDB può trasformarsi in un’avaria più seria. Il criterio è quindi: prima salute del disco e dei log, poi comando di servizio.

Per verificare che MySQL sia davvero operativo, oltre allo stato del servizio puoi controllare la porta e il socket. La porta standard è la 3306:

sudo ss -ltnp | grep 3306
ls -l /var/run/mysqld/

Se il socket non esiste, il client locale può fallire anche quando il demone sembra “quasi” partito. In quel caso il journal di MySQL è più utile della semplice uscita di systemctl. Cerca messaggi su permessi, InnoDB, crash recovery, spazio disco o errori di configurazione.

Un controllo rapido del disco è sempre sensato quando MySQL non sale:

df -h
sudo du -sh /var/lib/mysql

Se il filesystem è al 100%, il problema potrebbe non essere MySQL ma lo storage. In quel caso un restart ripetuto serve a poco: prima va liberato spazio o spostato il carico. Riavviare a ripetizione un database con storage saturo può peggiorare il recovery e ritardare l’analisi della causa iniziale.

Riavvio controllato: quando usarlo e quando evitarlo

Il comando restart è comodo, ma non sempre è la scelta migliore. Per Apache è accettabile quando hai cambiato configurazione o moduli e vuoi applicare tutto in modo pulito. Per MySQL è più delicato: se il motore è già in sofferenza, un restart può far emergere un problema latente che prima era solo nascosto, oppure può interrompere operazioni ancora in corso.

In un change controllato, la sequenza prudente è questa:

1. Salva una copia della configurazione toccata, ad esempio in un backup o in un repository di gestione config.
2. Valida la sintassi o la coerenza del servizio.
3. Esegui il riavvio solo se il controllo preliminare è pulito.
4. Verifica subito lo stato e i log.

Per Apache il backup tipico riguarda file come /etc/apache2/apache2.conf, /etc/apache2/sites-available/ e /etc/apache2/mods-available/. Per MySQL, il file di configurazione può includere /etc/mysql/my.cnf e gli snippet in /etc/mysql/mysql.conf.d/. Se fai modifiche, tieni traccia del diff: è il modo più rapido per fare rollback senza improvvisare.

Un esempio pratico di verifica prima del riavvio di Apache è questo:

sudo apache2ctl configtest
sudo systemctl reload apache2

Se il reload riesce, hai evitato un restart completo. Se fallisce, il problema è quasi sempre in configurazione, non nel demone. Per MySQL, invece, non esiste un equivalente universale del reload che sia sempre sicuro per ogni modifica: molte variazioni richiedono restart completo, quindi la verifica preventiva conta ancora di più.

Avvio automatico al boot

Su un server stabile, Apache e MySQL di solito devono partire automaticamente dopo il reboot. Questo dipende dallo stato di abilitazione dell’unità systemd. Se il servizio è disabilitato, il riavvio del server ti lascerà con il sito offline o il database non disponibile fino a intervento manuale.

Controlla e, se serve, abilita l’avvio automatico:

systemctl is-enabled apache2
systemctl is-enabled mysql
sudo systemctl enable apache2
sudo systemctl enable mysql

Lo stato atteso è enabled. Se trovi disabled, il servizio può funzionare adesso ma non dopo un reboot. È una differenza banale solo in apparenza: in produzione è uno dei motivi più comuni di “ieri andava, oggi no” dopo una finestra di manutenzione.

Quando il problema non è il servizio, ma il layer sotto

Non tutti i guasti si risolvono con start, stop o restart. Se Apache risponde ma il sito mostra errori, il collo di bottiglia può essere PHP-FPM, il database, la cache, o una risorsa esaurita. Se MySQL parte ma le applicazioni falliscono, il problema può essere un permesso errato sugli account, una password cambiata, un DNS non risolto verso repliche o una rete che blocca la porta 3306.

Per separare i livelli, fai una prova minima dall’host locale. Per Apache:

curl -I http://127.0.0.1
curl -I http://localhost

Per MySQL, se hai credenziali locali e autorizzate, prova una connessione semplice:

mysql -u root -p -e 'SELECT VERSION();'

Se Apache risponde localmente ma il sito pubblico no, il problema è più in alto nella catena: DNS, firewall, reverse proxy, CDN o bilanciamento. Se MySQL risponde localmente ma l’applicazione no, il problema è probabilmente nella configurazione applicativa, nei privilegi utente o nella stringa di connessione. Questo tipo di separazione evita di riavviare servizi sani quando il guasto è altrove.

Sequenza operativa consigliata in pratica

Se devi gestire i due servizi in modo ordinato, questa è una sequenza che funziona bene sia su server di sviluppo sia su macchine di produzione con cautela.

1. Verifica lo stato: systemctl status apache2 mysql --no-pager.
2. Leggi gli ultimi log: journalctl -u apache2 -n 20 --no-pager e journalctl -u mysql -n 20 --no-pager.
3. Controlla porte e socket: ss -ltnp e la directory socket di MySQL.
4. Valida la configurazione prima del riavvio: apache2ctl configtest per Apache.
5. Esegui restart solo se serve davvero, altrimenti usa reload quando supportato e sicuro.
6. Riconferma lo stato e fai una prova funzionale: pagina HTTP per Apache, query minima per MySQL.

Questa sequenza è meno elegante di un singolo comando, ma è molto più utile quando devi capire perché qualcosa non è salito. Ti lascia una traccia, riduce il rischio di restart ripetuti e ti aiuta a distinguere tra problema di servizio e problema di configurazione o storage.

Errori tipici da non ignorare

Ci sono alcuni segnali che meritano attenzione immediata. Se Apache fallisce con errore di binding sulla porta 80 o 443, probabilmente un altro processo sta già usando la porta. Se il file di configurazione ha un errore di sintassi, il servizio non partirà finché non correggi la direttiva. Se MySQL mostra crash recovery ripetuto, il problema può essere un filesystem danneggiato, file di log InnoDB incoerenti o spazio insufficiente.

Un altro errore comune è confondere attivo con funzionante. Un demone può risultare attivo ma non servire traffico corretto. Per questo gli indicatori più affidabili restano sempre tre: stato del servizio, log recenti e prova reale del servizio, cioè HTTP per Apache e query SQL per MySQL.

Rollback e ritorno a uno stato noto

Se un cambio rompe Apache o MySQL, il rollback deve essere rapido e prevedibile. Per Apache significa ripristinare il file o lo snippet di configurazione precedente e rifare il test sintattico prima del restart. Per MySQL significa tornare alla configurazione precedente, verificare che il percorso dati e i permessi siano corretti e riavviare solo dopo aver escluso corruzione o spazio insufficiente.

In pratica, il rollback corretto non è “riparto e vedo”. È: ripristino, verifico, riavvio, controllo. Se tieni i file sotto versionamento o almeno con backup puntuali, il tempo di recupero si riduce molto rispetto a un intervento manuale fatto a memoria.

Assunzione operativa: i servizi sono gestiti con systemd su Ubuntu recente e i nomi delle unità sono apache2 e mysql; se usi MariaDB o una distribuzione con naming diverso, sostituisci il nome dell’unità dopo averlo verificato con systemctl list-units --type=service.