[OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES

Tanu Kaskinen tanu.kaskinen at linux.intel.com
Thu Jul 16 18:44:12 UTC 2015


On Thu, 2015-07-16 at 11:21 -0700, Christopher Larson wrote:
> 
> On Thu, Jul 16, 2015 at 11:13 AM, Tanu Kaskinen
> <tanu.kaskinen at linux.intel.com> wrote:
>         On Thu, 2015-07-16 at 07:56 -0700, Christopher Larson wrote:
>         >
>         > On Thu, Jul 16, 2015 at 3:19 AM, Tanu Kaskinen
>         > <tanu.kaskinen at linux.intel.com> wrote:
>         >         On Mon, 2015-07-13 at 09:22 -0700, Christopher
>         Larson wrote:
>         >         >
>         >         > On Mon, Jul 13, 2015 at 9:17 AM, Pau Espin Pedrol
>         >         > <pespin.shar at gmail.com> wrote:
>         >
>         >         >         So, pulseaudio is intended to be used as a
>         systemd
>         >         user
>         >         >         service, not
>         >         >         as a systemd system service, and that
>         means it needs
>         >         to end up
>         >         >         in
>         >         >         /usr/lib/systemd/user and not
>         >         in /lib/systemd/system/.
>         >         >
>         >         >         All these changes are part of my efforts
>         to improve
>         >         systemd
>         >         >         user
>         >         >         service support in OE, which is kind of
>         bad nowadays
>         >         imho.
>         >         >
>         >         > Fair enough, thanks for the clarification. Given
>         that
>         >         systemd user
>         >         > services require pam, and most embedded distros
>         disable pam,
>         >         I wonder
>         >         > if we shouldn’t have an option, at least for
>         daemons in
>         >         recipes that
>         >         > can handle it, to switch from user to system via a
>         >         PACKAGECONFIG, and
>         >         > possibly default that for the non-pam case.. Hmm.
>         >
>         >         Do you mean that there are many distros that have
>         systemd but
>         >         don't have
>         >         pam, and that the lack of pam strongly suggests that
>         the
>         >         system won't
>         >         have any regular users? If so, then your proposal
>         sounds good.
>         >
>         > No, I mean that systemd user services require pam, as far as
>         I know,
>         > because it’s a systemd pam plugin which actually starts and
>         stops the
>         > user services. Without that hook, they won’t be run at all.
>         
>         
>         OK, then it's less clear that services should be run in system
>         mode by
>         default when pam isn't present. If the lack of pam doesn't
>         imply lack of
>         regular users, at least pulseaudio should still run as a user
>         service by
>         default (but not started by systemd if pam isn't enabled).
> 
> Running it as a user service by default when it’ll not actually ever
> be run, lacking a mechanism to run it, seems pretty pointless to me.
> If someone installs pulseaudio, presumably they want it to actually
> run.

PulseAudio can run as a user service without being a *systemd* user
service, and that's actually how it's commonly set up. PulseAudio is
typically started on demand via its own autospawn feature. The autospawn
feature will be replaced by systemd's socket activation in the future,
but only on systems that use systemd (and pam).

-- 
Tanu





More information about the Openembedded-core mailing list