Sfondo
Come tossico terminale, ho iniziato a scherzare con una combinazione di mpd (Music Player Daemon) e un giocatore, ncmpcpp (NCServes Media Player Client C ++).
Ho installato questi tramite Homebrew - un semplice brew install mpd ncmpcpp . Un po 'di configurazione dopo, e le app funzionano abbastanza bene. L'effetto è in realtà piuttosto impressionante:
Ilproblemachehoriscontratoèquandovoglioeseguirempdautomaticamenteinvecediavviarlonelmioterminale.Vienefornitoconunlaunchdplist,quindiloinstallo,esembrafunzionare-Ilproblemaèchequalunquecosaiostiasuonando,siachesiaunMP3,streamingaudiodaunserver,oqualsiasialtracosa,l'audiobalbettaogni5secondi
Questoassolutamentenonaccadequandompdvieneinvocatodirettamentedallarigadicomando,soloquandovienesparatovialaunchd.
Eccocomeappareilplist:
<!--homebrew.mxcl.mpd.plist--><?xmlversion="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>homebrew.mxcl.mpd</string>
<key>ProcessType</key>
<string>Interactive</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/opt/mpd/bin/mpd</string>
<string>--no-daemon</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>WorkingDirectory</key>
<string>/usr/local</string>
</dict>
Il ProcessType interactive è stato aggiunto da me nel tentativo di forzare launchd a dare priorità al daemon, senza alcun effetto.
Debug?
Se facciamo dtruss del processo, c'è un enorme esplosione di identici gettimeofday messaggi correlati a ogni balbuzie. Sembra così:
gettimeofday(0x10A03FD40, 0x0, 0x1000) = 1428698761 0
Cose che ho già eliminato
- CPU / disco IO
Il sistema è relativamente silenzioso - durante i balbettii, mpd non è nemmeno tra i primi 25 per l'utilizzo della memoria o della CPU, e il carico è ben inferiore a 1.0
- Ambiente errato che causa il caricamento di impostazioni di configurazione errate
La mia configurazione di mpd è quella che viene caricata da ~/.mpdconf , come quando la eseguo a mano.
Questo sembra essere un sintomo del modo in cui launchd sceglie di gestire il processo.
La domanda definitiva
Perché il daemon si comporta in modo anomalo quando viene eseguito con launchd, ma non quando viene eseguito tramite terminale?
Domanda bonus:
Che dire del modo in cui launchd avvia i processi potrebbe rendere evidente questo comportamento?