Il 06/04/25 11:07, Davide Prina ha scritto:
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.
Concordo e per la maggior parte delle volte è cosi. Per esempio su testing consigliano di lanciare 'apt modernize' (se non ricorco male) per modificare i source.list e renderli "moderni" ma è opzionale e non forzato. Sta cambiando qualcosa in Debian da questo punto di vista?
Chissa se questo cambiamento è stato pushato da Ubuntu...
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.
Questo non mi piace, anche io uso /tmp per elaborazioni. Però /var/tmp non sembra linkata a /tmp quindi potrebbe essere usata al posto di /tmp. Oppure per script/programmi si potrebbe usare /var/lib/programma/tmp
Io su una macchina virtuale con debian 12 aggiornata non vedo la tmp montata a parte (come la run su tmpfs):
udev 448M 0 448M 0% /dev tmpfs 97M 972K 96M 1% /run /dev/vda1 29G 16G 12G 59% / tmpfs 481M 1,1M 480M 1% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 97M 44K 96M 1% /run/user/0 tmpfs 97M 52K 96M 1% /run/user/1000 (ho mancato qualcosa?)
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
