Impossibile rimontare / tornare in sola lettura dopo l'aggiornamento del pacchetto

Sto usando Debian Stretch. La mia partizione di root è montata read-only. Solo quando installo o aggiorno i pacchetti, viene /rimontato read-write(usando l'hook apt), e poi rimontato su ro.

A volte dopo l'aggiornamento del pacchetto non riesco a rimontare /in sola lettura:

mount -o remount,ro /
mount: / is busy

Nelle versioni precedenti di Debian (Wheezy), potrei elencare i file aperti che sono stati scollegati con lsof:

 lsof +L1

o, più specificamente, i file che impediscono /di essere rimontati su ro:

{ lsof +L1 ; lsof|sed -n '/SYSV/d; /DEL|(path /p;' ; } | grep -Ev '/(dev|home|tmp|var)'

Tuttavia, su Debian Stretch, lsof +L1non elenca alcun file.

Non vedo alcuna modifica +|-Lin man lsofche spiegherebbe perché ha smesso di funzionare.

Perché lsof + L1 non elenca più i file aperti che sono stati scollegati?

Come posso elencare quei file che impediscono / di essere rimontati in sola lettura?

AGGIORNARE

Ho smesso di tutti i processi che possono essere fermate, e solo hanno inite gettytuttora in corso, ma non riesco ancora a rimontare /a ro.

Come posso elencare quei file che impediscono / di essere rimontati in sola lettura?

A) fusersi trova nel psmiscpacchetto; questo è un caso d'uso in cui trovo fuserbrillanti ed è più utile di lsof.

# fuser -v -m / 2>&1 | grep '[Ff]r.e'

Ciò mostrerà tutti i processi che hanno file aperti su / per la lettura (f) e la scrittura (F). I file che impedirebbero / di essere rimontati in sola lettura sono quelli aperti per la scrittura (F).

Uccidete i processi che sono un essere corsa eseguibile con directory root file aperti per la scrittura ., Vale a dire

# for fupid in $(fuser -v -m / 2>&1 | grep Fr.e | awk '{print $2}'); do kill $fupid; done

Questo è sopra i systemdcommenti con un avvertimento. Se systemdè initallora fuserlo vedrà e ci sono altre considerazioni. Con la systemdcorsa, può (ri) avviare i processi alle tue spalle, anche se sono stati appena identificati e uccisi fuser. systemdè molto più avanzato rispetto al tradizionale sysvinit.

B) L' aggiornamento nella descrizione indica che il sistema ha solo ... inite gettyancora in esecuzione ...

Vedo il commento che dice che il sistema non sta usando systemd, sta usando init. Sul tratto, systemd è init . Il commento non ha detto esplicitamente sysvinit, quindi presumo che il sistema in questione stia utilizzando il tratto predefinito systemdper init. O che le altre persone che inciampano in questo post, che usano stretch systemd, trovino utile questa parte.

Secondo il Debian Wiki ,

Il processo di inizializzazione del sistema è gestito dal demone init. In squeeze e nelle versioni precedenti, quel demone è fornito dal pacchetto sysvinit e non sono supportate alternative. In wheezy , il demone init predefinito è ancorasysvinit , ma è disponibile una "anteprima tecnologica" di systemd. In jessie e stretch , il sistema init predefinito èsystemd , ma il passaggio a sysvinit è supportato.

Da jessie, solo systemd è completamente supportato; sysvinit è principalmente supportato, ma i pacchetti Debian non sono richiesti per fornire script di avvio sysvinit. runit è anche impacchettato, ma non ha ricevuto lo stesso livello di test e supporto degli altri e non è attualmente supportato come PID 1.

Con l' systemdesecuzione, ci sono alcuni passaggi aggiuntivi che dovrebbero essere presi per liberare / in modo che possa essere rimontato senza problemi.

È probabile system.sliceche contenga file aperti per systemd-journald.serviceo systemd-udevd.service(entrambi i quali hanno dipendenze socket). Oppure, se NetworkManagerè in esecuzione, può rigenerarsi dhclientche scrive i contratti di locazione in / var / ... (& / var / non è sempre il suo dispositivo), ecc. fuserPotrebbe trovare e uccidere, dhclientma lo NetworkManagerriavvia subito.

La morale è che molte cose sono automatizzate che potrebbero "volere" / (e ancora di più con systemd).

A dire il vero, se è fattibile, l' systemdequivalente del livello di corsa 1 è abbinato a rescue.target(ed runlevel1.targetè un collegamento simbolico a rescue.target).

1) Inizia isolando il sistema a rescue.target

# systemctl isolate rescue.target

Dovrebbe essere richiesto di inserire la password di root; seguire le istruzioni sullo schermo.

2) Alla shell di salvataggio, scopri cosa vuole /.

# systemctl show -p Wants /

In genere lo è system.slice; fermare tutto ciò che vuole /. per esempio

# systemctl stop system.slice

3) A questo punto, il rimontaggio non dovrebbe riportare mount: / is busye mount -o remount,ro / dovrebbe funzionare. In caso contrario, controllare di nuovo con fuser.

4) FWIW; Ho anche visto momenti in cui umountfallisce quando / se un altro dispositivo è montato su una sottodirectory di un altro mount, ovvero montaggi nidificati. Ad esempio, umount /fallirebbe se / var / o / boot / si trova su un altro dispositivo (e montato). Anche se mount -o remount,ro /dovrebbe funzionare ancora in questo caso.

lsblk può essere utile per visualizzare montaggi nidificati.

Perché lsof + L1 non elenca più i file aperti che sono stati scollegati?

Poiché non sono disponibili (socket o la maggior parte dei FIFO e pipe), non sono più file aperti (il processo principale ha chiuso il descrittore di file) o hanno (ancora) un conteggio dei collegamenti maggiore di 1.

man lsof (8) dettagli ...

+ | -L [l]

Questa opzione abilita ('+') o disabilita ('-') l'elenco dei conteggi dei collegamenti ai file, dove sono disponibili - ad esempio, non sono disponibili per socket o la maggior parte dei FIFO e pipe.

Quando viene specificato + L senza un numero seguente, verranno elencati tutti i conteggi dei collegamenti. Quando viene specificato -L (impostazione predefinita), non verranno elencati i conteggi dei collegamenti.

Quando + L è seguito da un numero, verranno elencati solo i file con un numero di collegamenti inferiore a quel numero . (Nessun numero può seguire -L.) Una specifica del modulo '' + L1 '' selezionerà i file aperti che sono stati scollegati. Una specifica del modulo +aL1 <file_system>selezionerà i file aperti non collegati sul file system specificato.

Hai /procmontato?

Apparentemente qualcuno che si preoccupa di aver /montato in sola lettura per la maggior parte del tempo, posso immaginare che potresti anche scegliere di non montare procfs. Ma procfs è necessario per lsoftrovare file aperti.

I file tenuti aperti dai processi sono esposti dal kernel tramite collegamenti simbolici in procfs. Le directory /proc/<pid>/fdcontengono un collegamento simbolico per ogni file tenuto aperto. Il nome dei collegamenti simbolici sono i numeri dei descrittori di file e il percorso a cui fa riferimento il collegamento simbolico è il percorso del file.

Restano ancora attivi i collegamenti simbolici /procper i file aperti che sono già stati eliminati. E il percorso di riferimento del file viene rinominato per terminare con "(eliminato)".

Ciò lsof +L1che fa non è sostanzialmente diverso da un rapido one-liner come:

stat -c%N /proc/[0-9]*/fd/* | grep deleted

Quindi, è possibile utilizzare un one-liner simile per elencare tutti i file aperti che potrebbero impedire il rimontaggio del file system radice (a condizione che funzioni /proc).

Tuttavia, se hai / hai /procmontato, le uniche altre cause a cui riesco a pensare sono i bug ... Comunque, FYI, sul mio attuale sistema Debian Stretch. lsof +L1funziona come previsto.

bash# lsb_release -d
Description:    Debian GNU/Linux 9.5 (stretch)

bash# uname -a
Linux bwp-249-8 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux

bash# lsof -v
lsof version information:
    revision: 4.89
    [...]

Ho potuto riprodurre questo problema solo una volta e risolto semplicemente usando mountl' opzione -n .

Citando man mount :

-n, --no-mtab
      Mount without writing in /etc/mtab.  This is necessary for example when /etc is on a read-only filesystem.

Il mountprogramma stesso che ha aperto i file per la scrittura nel file system di root mi è sembrato una spiegazione plausibile. mountScrive specificamente /etc/mtabdopo tutto e /etcspesso fa parte del file system radice. Tuttavia non sono riuscito a riprodurlo nuovamente sulla stessa macchina dopo averlo fatto una volta ...

Questo potrebbe risolvere il tuo problema?

Senza visibilità nel tuo sistema, è molto difficile dirti esattamente qual è il problema. I commenti e le risposte precedenti sono buoni inizi.

Detto questo, vorrei tornare indietro nel wiki debian che descrive i prereq per il montaggio / sola lettura.

Il link alla documentazione è qui: https://wiki.debian.org/ReadonlyRoot

Quello grande ti guiderò qui:

1 - ci sono posizioni specifiche in / che devono essere lette in scrittura. Sulla base della documentazione è simile al seguente:

i dispositivi a blocchi saranno probabilmente diversi, a seconda della configurazione dello stack di archiviazione (partizioni, lvm senza partizioni, ecc.), ma l'idea principale è che sono necessari quei 4 punti di montaggio per avere il successivo filesystem montato per avere l'opzione di montaggio RW.

2 - ci sono un numero di file speciali in / etc che è necessario creare un collegamento simbolico o implementare qualche altra modifica (specificatamente dettagliata nell'articolo collegato.). Questi possono o meno essere applicati in base alle applicazioni in esecuzione sul server Linux. alcuni file potrebbero non esistere sul tuo computer, ma ho incluso tutto nei documenti. Tieni presente che consiglio vivamente di apportare queste modifiche ANCHE SE hai ucciso il pid del processo. Ecco i percorsi direttamente dal wiki debian:

• adjtime
• init.d / alsa-utils
• / Etc / courier / shared / index
• qualsiasi file di stato tazze, classes.conf, cupsd.conf, printers.conf subscriptions.conf
• /etc/lvm/lvm.conf
• mtab (a cui sembra che tu abbia tentato di rispondere dando a mount il flag -n)
• network / run (usato da ifup e ifdown, in squeeze. potrebbe non applicarsi a stretch, ymmv)
• nologin
• resolv.conf
• sia i file passwd che quelli shadow
• samba / dhcp.conf
• succhiare
• udev

Dopo aver verificato tutto quanto sopra e confermato che sono conformi alle specifiche nel wiki, la prossima cosa da controllare è /etc/apt/apt.conf

DPkg {
// Auto re-mounting of a readonly /
Pre-Invoke { "mount -o remount,rw /"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro / || true"; };
}; 

in base al tuo errore, l'ultima cosa che puoi controllare in base alla documentazione proviene da quanto segue:

"Dopo un aggiornamento dei pacchetti potresti dover affrontare il problema che mount rifiuta di rimontare di nuovo il filesystem dicendoti" / è occupato ". Ciò è causato dai file eliminati che vengono comunque utilizzati da un processo.Per scoprire quali processi utilizzano i file eliminati, utilizzare lo strumento checkrestart (1) dal pacchetto debian-goodies o utilizzare il comando seguente: spesso si tratta di demoni che utilizzano librerie aggiornate. devi riavviarli per far rilasciare i file. "

comando fornito nel documento .:

{lsof +L1; lsof|sed -n '/SYSV/d; /DEL\|(path /p;'} |grep -Ev '/(dev|home|tmp|var)'

Senza conoscere la configurazione esatta del filesystem, il partizionamento e la configurazione del dispositivo di archiviazione, è difficile darti molto altro da seguire. Vorrei iniziare tornando indietro e ricontrollando i tuoi prereq nella documentazione (e delineati sopra).