My ALSA Seq port manager runs as a service. The service is installed under its own service user, which has the home directory set to some place non-existent and non-writable.
When my service starts I see this surprising log message:
*amidiminder[136345]: Failed to create secure directory (/var/lib/misc/.config/pulse): No such file or directory*
A little investigation reveals that this error is generated by this call, opening the ALSA Seq:
serr = snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0);
It's a little surprising that opening ALSA Seq would somehow invoke something in pulse audio, and further that pulse audio would then be trying to create its user directory (.configure/pulse is where pulse audio sticks things under each user's home directory).
This seems to be a reprise of this Debian bug from 2013 involving alsa-utils and pulse audio:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712980
Which was close via this patch to alsa-utils:
alsactl: Make homedir configurable https://mailman.alsa-project.org/hyperkitty/list/alsa-devel@alsa-project.org/thread/L2RDVYRA5R3VQIXFS4TGKU4DIA4IFPWW/#L2RDVYRA5R3VQIXFS4TGKU4DIA4IFPWW
The fix there seems to be adding some mechanism to change the $HOME environment variable to point at /var/run/alsa. I agree with Takashi's reply to that fix: Overriding $HOME sounds scary to me, too!
Is there any insight into this... and did that fix stick or was some other method found to deal with this. In my case, I don't understand why just opening the ALSA Seq is causing any pulse audio code to run... but perhaps things are more entwined at a lower level of ALSA lib than I understand.
- Mark