|Home • About • Community • Download • Documentation • Planet|
[[!format rawhtml """
Running PulseAudio as System-Wide Daemon
Starting with PulseAudio 0.9.3 the daemon can be run as a system-wide instance which than can be shared by multiple local users. We recommend running the PulseAudio daemon per-user, just like the traditional ESD sound daemon. In some situations however, such as embedded systems where no real notion of a user exists, it makes sense to use the system-wide mode.
Before you now go ahead and use it please read about what is wrong with system mode.
To run PulseAudio in system-wide mode, start it as
root and pass the
--system argument to it. It will then drop priviliges and change to the
pulse UNIX user and group. The directory
/var/run/pulse/ is used as home directory. In this mode the module
module-native-protocol-unix will automatically allow access to all members of the group
pulse-access. All user/group names and paths can be changed by passing compile-time arguments to
configure. The system user
pulse and the groups
pulse-access need to be created manually. On Debian this works like this:
[[!format txt """ addgroup --system pulse adduser --system --ingroup pulse --home /var/run/pulse pulse addgroup --system pulse-access
Some distributions restrict access to the sound devices to a group audio
adduser pulse audio
Add a user to the pulse-access group
adduser lennart pulse-access
The runtime directory
/var/run/pulse is created automatically on daemon startup. This directory contains the .esd_auth file, which is the authentication cookie for esound. If you want to use esound without disabling authentication, create a symlink from this file in your home directory:
[[!format txt """ ln -sf /var/run/pulse/.esd_auth ~/.esd_auth """]] Please note that creating these groups/users is not necessary when running the PulseAudio in the traditional per-user setup
Running PulseAudio in system-wide mode has some limitations:
- All users with access to the sound server cann kill/modify all sinks/sources and streams of all other connected clients
There is only a single namespace for cached sound samples, i.e. there can be only a single Gnome event sound profile active at the same time It has some disadvantages:
Worse security, because the user can now command a server app running under another user name. He could even load/unload modules from that sound server
- Settings like the stored volume levels managed by
module-volume-restoreare no longer per-user but system-wide Read more about what is wrong with system mode.
If the system-wide mode is enabled it is advisable to disable module loading during runtime by passing
--disallow-module-loading to the daemon, to inhibit the user from loading arbitrary modules with potentially vulnerable code into the daemon. However, this might break some modules like
module-hal-detect which will load a sound driver module each time HAL signals that a new sound card became available in the system.