pulseaudio system process fails with "q overrun" when under system load
I have a headless media server on which I'm running pulseaudio as a system service, so that it starts at boot and keeps running when no one's logged in. It works fine, but I have one heavy cron job that runs once a day and uses a significant amount of disk IO. At these times, I see this in the syslog:
May 1 06:19:08 donbot pulseaudio: 485 events suppressed May 1 06:19:08 donbot pulseaudio: q overrun, queuing locally May 1 06:19:08 donbot pulseaudio: message repeated 6 times: [ q overrun, queuing locally] May 1 06:19:11 donbot systemd: pulseaudio.service: Main process exited, code=killed, status=9/KILL May 1 06:19:11 donbot systemd: pulseaudio.service: Failed with result 'signal'.
I could (and probably will) add a Restart clause to my pulse unit file, but I'd prefer to try and massage the configuration so that pulse doesn't die in the first place, because I also have cron jobs that need to play audio.
I noticed that the pulse page on system mode (and why not to use it) mentions:
When in system mode, shared memory data transport is disabled for security reasons, which means: much higher memory usage and CPU load in system mode
though I don't notice pulse taking significant resources when playing music. Also, this problem only started when I upgraded to Ubuntu 18.04, and began running pulse as a system service. (My previous setup auto-logged in on a physically-connected session to auto-start pulse, which I'd like to avoid.)
Is there an adjustment I can make to my pulse setup so that I don't have this issue? Systemd unit is below:
[Unit] Description=PulseAudio system server [Service] Type=notify ExecStart=/usr/bin/pulseaudio --daemonize=no --system --realtime --log-target=journal [Install] WantedBy=multi-user.target
Note that I'm not using the --no-cpu-limit flag. It wasn't clear to me that giving pulse a license to go nuts in all circumstances was a fix. Also, I ran a test that pegged my cpu load at 100%, and pulse didn't even stutter - no errors in the log. So it feels like it's probably the disk IO, not the cpu.