# Pulizia del sistema (/tmp)

## GuN_jAcK

Ragazzi avrei una domanda...

In questi giorni sto facendo un po di pulizie sul disco perchè sopra c'è stratificata la peggio roba  :Very Happy:   :Very Happy: 

Andando a spulciare nella dir /tmp ho visto che ci sono una marea di temporanei, anche robba che avevo sul disco un anno fa   :Shocked: 

Ma da quanto ne sapete.. il contenuto della dir /tmp può essere completamente rimossa? Sono un totale di 8 Gb... mica per altro.. incluse alcune ISO di DVD on the fly che ho fatto con K3b   :Embarassed: 

----------

## Scen

Vai tranquillo, pialla senza pietà il contenuto di /tmp.

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES

 *Quote:*   

> 
> 
> /tmp : Temporary files
> 
> Purpose
> ...

 

----------

## gutter

Forse questo potrebbe interessarti:

```

# /etc/conf.d/bootmisc

# Put a nologin file in /etc to prevent people from logging in before

# system startup is complete

DELAYLOGIN="no"

# Should we completely wipe out /tmp or just selectively remove known

# locks / files / etc... ?

WIPE_TMP="yes"

```

----------

## GuN_jAcK

vi ringrazio ragazzi  :Very Happy:  non potevo chiedere di meglio!  :Smile: 

----------

## Kernel78

 *GuN_jAcK wrote:*   

> vi ringrazio ragazzi  non potevo chiedere di meglio! 

 

a dire il vero potresti guardare anche tmpwatch, io lo trovo molto comodo ...

----------

## Cazzantonio

Io monto direttamente la /tmp in tmpfs

----------

## Peach

 *Kernel78 wrote:*   

>  *GuN_jAcK wrote:*   vi ringrazio ragazzi  non potevo chiedere di meglio!  
> 
> a dire il vero potresti guardare anche tmpwatch, io lo trovo molto comodo ...

 

mi sfugge una cosa di tmpwatch:

```
# NOTE: if you have noatime in /etc/fstab for any partitions you plan on

# running tmpwatch on, you should obviously change any of the examples that

# use atime (-u|--atime).  Those that don't specify anything, default to 

# atime.
```

visto che ho la root in "noatime" come dovrei modificare uno script del genere?

```
# Delete everything in /tmp that haven't been accessed in a week (>=168 hrs).

#

if [[ -d /tmp ]]; then

  ${TMPWATCH} --atime 168 /tmp

fi
```

 :Question: 

----------

## Scen

Potresti sostituirlo con mtime o ctime, rispettivamente data ultima modifica e data creazione.

----------

## Peach

 *Scen wrote:*   

> Potresti sostituirlo con mtime o ctime, rispettivamente data ultima modifica e data creazione.

 

giusta osservazione, grazie

----------

## Kernel78

 *Peach wrote:*   

>  *Scen wrote:*   Potresti sostituirlo con mtime o ctime, rispettivamente data ultima modifica e data creazione. 
> 
> giusta osservazione, grazie

 

“Danger, Will Robinson!”  :Laughing: 

Scherzi a parte, attenzione ad usare ctime o mtime, altrimenti si corre il serio rischio che il file a cui accedi tutti i giorni ma che hai creato/modificato l'ultima volta diversi anni fa venga cancellato, va bene che dovresti far puntare solo a directory per file temporanei e che in quelle directory non dovresti tenerci file permanenti ma penso sia meglio specificare i rischi che si corrono.

Sarà poi che trovo che l'incremento prestazionale dato dal noatime decisamente non all'altezza di aver la disponibilità del momento di ultimo accesso ai vari file.

----------

## djinnZ

infatti usando ctime (ma anche con mtime) rischi che ti vengano piallati tutti i semafori in tmp. Una delle tante ragioni (per me è la seconda dopo la necessità di isolare le aree a scrittura frequente da quelle del sistema etc.) per usare un partizionamento complesso.

In realtà noatime ti serviva solo per l'accoppiata lilo+reiserfs e per guadagnare qualcosa in prestazioni (su sistemi multiutente non workstation però) o per ridurre gli accessi al disco su un portatile.

----------

## Ic3M4n

il problema dei semafori o in generale di dover utilizzare un sistema di monitoraggio di /tmp è una cosa che secondo me deve essere vagliata su sistemi up 24/7. per il resto, quindi la maggior parte dei sistemi desktop, è sufficiente il WIPE_TMP. dopotutto se un programma utilizza /tmp per dei dati temporanei non gli servono dopo il successivo riavvio del programma, quindi anche del sistema. se deve tenere qualche schifezza in giro usi pure /var/tmp.

 *Cazzantonio wrote:*   

> Io monto direttamente la /tmp in tmpfs

 

e non hai mai avuto problemi? tipo sw per masterizzare che creano la iso in /tmp?

----------

## !equilibrium

 *Peach wrote:*   

> visto che ho la root in "noatime" come dovrei modificare uno script del genere?

 

semplicemente usando relatime al posto di noatime.

non perdi i benefici di noatime ma non ti tiri dietro tutto l'overhead I/O di atime.

----------

## Kernel78

 *!equilibrium wrote:*   

>  *Peach wrote:*   visto che ho la root in "noatime" come dovrei modificare uno script del genere? 
> 
> semplicemente usando relatime al posto di noatime.
> 
> non perdi i benefici di noatime ma non ti tiri dietro tutto l'overhead I/O di atime.

 

Sai indicarmi della documentazione a riguardo ?

----------

## !equilibrium

 *Kernel78 wrote:*   

> Sai indicarmi della documentazione a riguardo ?

 

certo --> Replacing atime With relatime

----------

## cloc3

  *!equilibrium wrote:*   

> 
> 
> certo --> 

 

quando si muove equilibrium! c'è qualcosa di importante da dire.

la discussione mi pone molte domande. alcune vi appariranno scontate, e chiedo scusa fin d'ora.

1. a quanto pare fin d'ora era necessario scegliere esplicitamente l'opzione noatime per avere dei vantaggi di prestazioni. Si può ritenere che, a breve, mount sceglierà di default l'opzione più favorevole (ovvero relatime)?

2. come mai un problema un problema sistematico così evidente è stato sollevato solo ora, nel 2007, a oltre 15 anni di vita di Linux e quaranta ormai tondi di Unix?

3. una risposta parziale alla domanda 2 potrebbe venire dall'intervento di Jörn Engel che non rileva sul proprio hardware una grande differenza. Quali sono gli hardware dove la scelta è veramente importante? Esistono altri vantaggi, oltre alle prestazioni, nel limitare le scritture superflue (per esempio, la maggior vita dell'HD)?

4. nel thread si fa continuo riferimento ad ext3. per gli altri filesystem la questione ha la stessa rilevanza?

5. ... 

scommetto che ci sono ancora 200 domande sul tema. ma per adesso mi fermo qui. 

----------

