Perché / var / run è stato migrato su / run?

66

Dalla panoramica tecnica di Ubuntu 11.10 Oneiric :

  

Ubuntu 11.10 è migrato lontano da /var/run , /var/lock e /dev/shm e ora usa /run , /run/lock e /run/shm invece (rispettivamente).

  • Ho codificato questi percorsi nelle mie applicazioni, perché questa modifica è stata apportata a Oneiric?
  • Che cosa posso fare per rendere le mie applicazioni indietro e compatibili con il futuro? C'è un modo migliore se non verificare prima l'esistenza di /run e poi /var/run ?
posta Lekensteyn 16.08.2011 - 11:08

5 risposte

57

L'intento è ridurre il numero di file system tmpfs . In data 11.04, ci sono sistemi di file tmpfs separati a /var/lock , /var/run e /dev/shm . Se queste directory si trovassero tutte in una singola directory principale, sarebbe necessario un solo tmpfs . Fornisce anche una posizione ovvia per ulteriori dati sullo stato di runtime che non dovrebbero persistere nei riavvii.

A meno che la tua applicazione non dipenda dai percorsi canonici dei file, la tua applicazione dovrebbe essere eseguita senza modifiche poiché le vecchie posizioni saranno collegate simbolicamente a quelle nuove. Le politiche di AppArmor sono un caso che dipende dai nomi dei percorsi reali, motivo per cui è stato menzionato in modo specifico.

I seguenti collegamenti dovrebbero aiutare a spiegare la logica:

risposta data James Henstridge 16.08.2011 - 11:56
36
  1. /run è una nuova posizione di tmpfs di distribuzione incrociata per la memorizzazione di file di stato transitori, ovvero file contenenti informazioni di runtime che possono o non devono essere scritte all'inizio del processo di avvio e che non richiedono preservando attraverso i riavvii.

    Rendere la directory /run disponibile ci avvicina di un passo al punto in cui è possibile utilizzare il sistema normalmente con il filesystem di root montato in sola lettura, senza richiedere soluzioni alternative come aufs/unionfs overlay.

    /run sostituisce diverse posizioni esistenti descritte nello standard della gerarchia del filesystem:

    • /var/run/run
    • /var/lock/run/lock
    • /dev/shm/run/shm [attualmente solo Debian pianifica di farlo]
    • /tmp/run/tmp [opzionale; attualmente solo Debian prevede di offrire questo]
    • /run sostituisce anche altre posizioni che sono state utilizzate per i file temporanei:

    • /lib/init/rw/run

    • /dev/.*/run/*
    • /dev/shm/*/run/*
    • file scrivibili sotto /etc/run/*

    (quindi probabilmente puoi aspettarti che si spostino anche loro).

    Fonte: obiettivi di rilascio debian

  2. Consiglierei di creare una parte nel tuo software in cui imposti queste directory in variabili, cambia il tuo codice per usare queste variabili e poi altera le variabili in base al sistema su cui è usato (ma scommetto che sapevi già).

risposta data Rinzwind 16.08.2011 - 11:50
5

Da quello che ho letto, questa è stata la spiegazione originale del perché / run è stata introdotta. link

    
risposta data gotunandan 16.08.2011 - 11:49
3

Nota: poiché / run introduce, piccole configurazioni potrebbero avere problemi. Il mio server Ubuntu è 256Mo RAM e / run è di default impostato su 49Mo.
All'avvio, riempie il filesystem fino alla pienezza.
Apportare modifiche in fstab non funziona per aumentare le dimensioni di esecuzione / temps. Né le altre procedure che ho trovato su gg.
Ho trovato la soluzione da aggiungere nello script init: /etc/rc.local la riga     %codice% da estendere all'avvio. (L'85M è per il mio conf.)

    
risposta data korrident 02.09.2012 - 14:48
2

Non dovresti inserire hardcode in nessuno di questi percorsi /run !

  • Utilizza /var/run , perché un link simbolico sarà presente a /run se applicabile
  • /var/lock è uguale a sopra
  • Non hardcode /dev/shm mai, usa sempre shm_open etc (l'API posix)
risposta data ramslök 10.07.2012 - 13:45

Leggi altre domande sui tag