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@xxxxxxxxxxxxxxxx/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
