ho scoperto che la mia /tmp è stata spostata da / (inteso che era
parte di / e non montata sotto /) dove prima era in tmpfs, in
pratica in RAM.
Non so se mi è sfuggita la modifica data da aptlistchanges, però non
mi sembra una buona cosa far fare questo passaggio in automatico senza
per lo meno avvertire gli utenti (dato che non tutti in ogni caso
usano aptlistchanges) e soprattutto indicare come evitare che questo
avvenga. Secondo me la cosa migliore era chiedere all'utente se voleva
fare questo passaggio e in caso negativo lasciare tutto così com'era.

Questo è negativo soprattutto per chi ha poca RAM, perché se la vede
erodere da questo esplodere d'uso di tmpfs che non sono altro che
dischi "virtuali" in RAM, al posto che su un disco di storage. Inoltre
chi ha poca RAM si vedrà usare lo swap per aumentare "virtualmente" la
RAM per permettere di creare un disco "virtuale" in RAM.

Chi, come me, usava /tmp, per buttarci dentro file e fare elaborazioni
non potrà più farlo, perché tale directory avrà uno spazio molto
limitato e per buona parte già usato dal sistema.

Dopo aver capito che qualcosa non andava, prima perché una mv da /tmp
ad altra directory anch'essa sotto / ci aveva messo un po' e non era
stato immediato come al solito e poi con un bell'errore del tipo
"spazio su disco esaurito", ho visto che /tmp era diventata di tipo
tmpfs e cercando ho trovato che questa è una cosa voluta per l'uscita
di Trixie[¹]. Però nessuno si è chiesto se questo potrebbe far fallire
un upgrade a Trixie? Mi sembra che questi metodi per obbligare le
persone a cambiare computer sono adottati da altri... fino a quando
ho trovato che in realtà non tutti sono così favorevoli a questo cambio
e per buoni motivi[²], anche se era nell'ormai lontano 2012, in fondo
c'è un link anche a lwn.net con un articolo che parla proprio di questo.

In ogni caso io ho un sistema con 4GB di RAM e assegnarne 2GB per /tmp
mi lascia con troppa poca RAM. Nel mio caso questa "soluzione" è un
disastro. Per fortuna sto usando labwc e non Gnome, il mio DE precedente
fino a poco tempo fa, probabilmente non mi sarebbe neanche partita l'interfaccia grafica o se partiva tutto sarebbe stato lentissimo con
swap su disco senza fine.

Notare anche che si vuole usare tmpfs anche per altre porzioni di
filesystem.
Questo potrebbe obbligare a ripensare all'uso dello swap anche a chi lo
aveva eliminato perché pensava di avere sufficiente RAM per ogni
"occasione".

Per sapere dov'è attualmente usato basta un
$ df -h | grep tmpfs

tmpfs permette di creare un filesystem virtuale temporaneo, la cui
persistenza, se non erro, dovrebbe essere di 10 giorni. Quindi in ogni
caso il contenuto deve andare a finire su disco da qualche parte. Inoltre
tale filesystem ha una dimensione virtuale massima, ma si
allarga/restringe in automatico a seconda di quanto contenuto ha in esso.

Detto questo come si fa a disabilitare l'uso di tmpfs per /tmp?

Per vedere come è montato /tmp si può usare una delle seguenti istruzioni:
$ systemctl cat tmp.mount
$ systemctl cat /tmp

Se si vuole vedere ogni mount effettuato tramite systemd
$ systemctl cat *.mount

Per disabilitarlo penso basti questo:
# systemctl mask tmp.mount

sul wiki di archlinux[³] ho trovato che è corretto, ma questo fa si che
/tmp poi venga svuotato ogni 10 giorni, per farlo svuotare
automaticamente ad ogni avvio bisogna usare tmpfiles.d(5)
Nel file /etc/tmpfiles.d/tmp.conf aggiungere la seguente riga
D! /tmp 1777 root root 0

al posto di quella che c'è (meglio aggiungere questa e commentare quella precedente).

Ho visto che c'è anche un altro tmpfs montato per /dev/shm, però:
tmpfs 2,0G 336K 2,0G 1% /dev/shm

quindi vuol dire che dovrebbe occupare 366K di RAM, ma

$ cat /proc/meminfo | grep -i Shmem
Shmem: 359396 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB

però qui mi dice che occupa 359MB... qualcosa non torna da quanto avevo capito.

Questo è l'unico tmpfs che occupa, come massimo, una dimensione
ragguardevole, gli altri sono molto limitati.

Riprovando oggi, dopo aver disabilitato tmpfs per /tmp le cose invece
tornano
$ cat /proc/meminfo | grep -i Shmem
Shmem: 23392 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB

$ free -h
mi ritorna shared pari a 22MB

infatti in
$ man free
[...]
shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo)
[...]

tenendo conto che ieri /tmp occupava quasi 2GB e gli altri tmpfs erano
al massimo di qualche MB quando avevo eseguito le istruzioni sopra
riportate.

Infine posso confermare che oggi, dopo aver rimesso /tmp sul disco
contenente / e aver indicato di svuotarlo ad ogni riavvio, tutto è
tornato a funzionare correttamente, dove correttamente è inteso nel
mio caso.

Ciao
Davide

[¹]
https://news.itsfoss.com/debian-13-tmp-mounting/

[²]
https://lists.debian.org/debian-devel/2012/06/msg00311.html

[³]
https://wiki.archlinux.org/title/Tmpfs


--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)