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