Notifica delle modifiche su un file in / proc

13

Ho scritto un piccolo 'demone' in bash che passerà alle cuffie se vengono rilevate e, in caso contrario, passerà a un altoparlante USB esterno con PulseAudio.

Quello che sto cercando è un modo per ottenere la notifica delle modifiche al file /proc/asound/card0/codec#0, proprio come inotifywaitsui file reali (considerando i file in / proc come "pseudo-file").

Trovo il mio codice un po 'folle, perché si corre sleep 1con awkper tutta la giornata, che è 86400 volte al giorno :)

while sleep 1; do
    _1=${_2:-}
    _2=$(awk '/Pin-ctls/{n++;if(n==4)print}' '/proc/asound/card0/codec#0')

    [[ ${_1:-} = $_2 ]] ||
        if [[ $_2 =~ OUT ]]; then
            use_speakers
        else
            use_internal
        fi
done

Quello che sto cercando è qualcosa di simile (questo esempio non funziona):

codec=/proc/asound/card0/codec#0
while inotifywait $codec; do
    if [[ $(awk '/Pin-ctls/{n++;if(n==4)print}' $codec) =~ OUT ]]; then
        use_speakers
    else
        use_internal
    fi
done

In questo modo i comandi all'interno del ciclo verrebbero eseguiti solo in presenza di modifiche reali sul $codecfile.

proc inotify

— Teresa e Junior
fonte

1

Non è pazzesco: cose come tope i monitor di sistema della GUI leggono molto più di questo da /procbrevi intervalli. Naturalmente, probabilmente lo fanno in modo molto più efficiente come eseguibili compilati, ma il punto è: il polling per le informazioni è un compito comune.

— Riccioli d'oro,

2

Poiché il problema sottostante non è unico per te, mi aspetto che ci sia una soluzione pronta (almeno per alcuni componenti hardware) - dai un'occhiata a unix.stackexchange.com/questions/25776/… e superuser.com/questions / 339900 /… . Il sorgente ultimo è ovviamente l'albero del kernel (e le specifiche hardware se decidi di implementarlo in qualche driver).

— peterph,

1

Se questo si presenta in /proc, probabilmente puoi attivare il tuo script con una regola udev , che sarebbe piuttosto ideale. Meno ideale è quanto possa essere noioso elaborare regole udev;)

— goldilocks

@peterph Da quello che ho potuto raccogliere, hda-verb fornisce un'interfaccia per l'impostazione o il controllo dei parametri, ma sembra che dovrò eseguirlo anche ogni secondo.

— Teresa e Junior,

@goldilocks Il collegamento delle cuffie non invia alcun evento udev. O c'è qualcosa in più che mi manca?

— Teresa e Junior,

10

Quello che sto cercando è un modo per ottenere la notifica delle modifiche al file [in proc]

Non puoi, perché non sono file. Questa non è una domanda abbastanza duplicata, ma la risposta qui spiega perché.

/procè un'interfaccia del kernel. Non ci sono file reali lì, quindi non possono cambiare. La lettura dagli handle è una richiesta e i dati nel file quando lo leggi è una risposta a questo.

L'unico modo per simulare qualcosa del genere sarebbe leggere il file ad intervalli e confrontare il contenuto per vedere se la risposta del kernel è cambiata - sembra che tu l'abbia già fatto.

Se statprocedi ai file, atime e mtime saranno gli stessi: per alcuni file è ogni volta che è stata la chiamata stat, per altri un tempo dall'avvio del sistema. Nel primo caso, sembrerà sempre cambiato, nel secondo non sembrerà mai cambiato.

— goldilocks
fonte

Sfortunatamente, anche il polling ogni secondo aggiunge una latenza considerevole (ad es. 500ms). Speravo che ci sarebbe stato un modo più rapido / efficiente per farlo, ma dal momento che hai detto che le app come top lo fanno allo stesso modo, penso che lo lascerò in quel modo.

— Teresa e Junior,

@TeresaeJunior Se la latenza è un problema (penso che non sia qui), ad esempio, poiché la durata del sondaggio viene utilizzata in un calcolo, dovresti cronometrare la durata effettiva (e non usare solo il tempo che hai chiesto di dormire) . Sembra molto però; Non ho mai profilato script bash quindi non so cosa sarebbe normale qui (hmm ... bella domanda separata). Invocare awk == fork()e cose del genere è costoso; le utility scritte tutte in C avrebbero, come detto, metodi più veloci. Continuo a non pensare che tu stia aggiungendo molto carico al sistema in generale.

— Riccioli d'oro,

1

No, scusa, in realtà intendevo: dal momento in cui collego le cuffie al sonno successivo c'è un notevole ritardo. Ma non ho intenzione di ridurre il tempo di sonno. Grazie per l'aiuto!

— Teresa e Junior,

4

Se si utilizza PulseAudio, lo pactl subscribefa.

— user66233
fonte

si Certamente. Ho iniziato a usarlo dopo aver compilato PA 4.0 alcuni mesi fa a causa di alcuni problemi audio. La versione su Debian Stable è 2.0 (anche se recentemente hanno caricato 4.0 nei backport), e non ce n'era subscribesu 2.0.

— Teresa e Junior,

2

Inoltre, tieni presente che alcuni file /proc/consentiti possono essere monitorati per le modifiche tramite polling, ad esempio se man procpuoi leggere quanto segue sul /proc/self/mountsfile:

/ proc / [pid] / mounts (da Linux 2.4.19) Questo file elenca tutti i filesystem attualmente montati nello spazio dei nomi di mount del processo (vedi mount_namespaces (7)). Il formato di questo file è documentato in fstab (5).

Dalla versione 2.6.15 del kernel, questo file è pollable: dopo aver aperto il file per la lettura, una modifica in questo file (ovvero un mount o unmount del filesystem) fa sì che select (2) contrassegni il descrittore del file come una condizione eccezionale, e poll (2) e epoll_wait (2) contrassegnano il file con un evento prioritario (POLLPRI). (Prima di Linux 2.6.30, una modifica di questo file era indicata dal descrittore di file contrassegnato come leggibile per select (2) e contrassegnato come avente una condizione di errore per poll (2) ed epoll_wait (2).)

Ed è esattamente ciò che viene implementato nella seguente domanda:

/programming/5070801/monitoring-mount-point-changes-via-proc-mounts

— Nelson
fonte

-1

Prova a utilizzare netlinkper monitorare i /procfile modificati.

https://mdlayher.com/blog/linux-netlink-and-go-part-1-netlink/

— meyao
fonte

Benvenuti nel sito. Si prega di aggiungere alcune spiegazioni su come utilizzare netlinkper raggiungere tale compito; non risulta dal contenuto esterno collegato. Inoltre, in generale si preferisce non avere risposte "solo link" poiché il contenuto esterno può cambiare o essere rimosso (vedere l'avviso nella parte superiore della pagina originariamente collegata, ad esempio), che ridurrebbe l'utilità del tuo contributo.

— AdminBee