Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
Hi,
2015-07-16 20:44 GMT+02:00 Tanu Kaskinen tanu.kaski...@linux.intel.com:
On Thu, 2015-07-16 at 11:21 -0700, Christopher Larson wrote:
On Thu, Jul 16, 2015 at 11:13 AM, Tanu Kaskinen
tanu.kaski...@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.kaski...@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.s...@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).
The autospawning without using systemd is not affected by the
modification done in this patch afaik, because it is not enabling the
systemd user service, only installing the service file.
So, If you agree, I will create a patch for bitbake.conf to
1 - add:
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
2 - Also change systemd_unitdir to use nonarch_libdir.
3 - Then I will create v3 for this patch using systemd_user_unitdir.
Maybe also modify the recipe a bit to use systemd_system_unitdir for
the system service.
--
Tanu
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Wed, 2015-07-22 at 17:31 +0200, Pau Espin Pedrol wrote:
Hi,
2015-07-16 20:44 GMT+02:00 Tanu Kaskinen tanu.kaski...@linux.intel.com:
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).
The autospawning without using systemd is not affected by the
modification done in this patch afaik, because it is not enabling the
systemd user service, only installing the service file.
So, If you agree, I will create a patch for bitbake.conf to
1 - add:
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
2 - Also change systemd_unitdir to use nonarch_libdir.
3 - Then I will create v3 for this patch using systemd_user_unitdir.
Maybe also modify the recipe a bit to use systemd_system_unitdir for
the system service.
About that last point: PulseAudio doesn't currently ship a .service file
for running in the system mode, so I don't know what modification you
exactly mean.
Otherwise I see no problems in your plan.
--
Tanu
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
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.s...@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. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Mon, 2015-07-13 at 12:23 +0200, Pau Espin Pedrol wrote:
Hi,
I am not sure which is the behavior with those paths right now and how
it should be.
I just checked this:
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path
So, it seems according to documentation that system services should be
installed under /usr/lib/systemd/system, but currently they are
installed in /lib/systemd/system in my generated image. Is that a
expected behaviour? Shouldn't we try to follow documentation? I see
that sometimes /lib/systemd/system path is appended to the dirs in
systemdsystemunitpath, but it's not stated in the documentation,
that's a bit strange.
For user services, /usr/lib/systemd/user is already being used as
stated in docs.
Now, when multilib comes in, I get lost. If I understand correctly,
with multilib enabled we have too /lib64 and /usr/lib64. Are then
systemd service files suppoused to be installed in /usr/lib/systemd/
or in /usr/lib64/systemd/ ? If I undersood correctly your comment you
meant they should still be going into /usr/lib/systemd right?
Now, talking about bitbake.conf. I see there's already a line with the
following:
export systemd_unitdir = /lib/systemd
So, apart from your nonarch issue, I think it would also be a good
idea to split systemd_unitdir into system and user, as done by
provided pc in systemd (src/core/systemd.pc.in):
1- If still want system services to be in /lib and user services to be
in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
2- If you want both in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
This thread is still lacking a conclusion about how to set up the
unitdir variables in bitbake.conf. FWIW, in my opinion this is the best
option:
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
systemd_unitdir with the old value probably needs to be kept around for
compatibility, though.
--
Tanu
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Thu, Jul 16, 2015 at 3:19 AM, Tanu Kaskinen tanu.kaski...@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.s...@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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Thu, 2015-07-16 at 07:56 -0700, Christopher Larson wrote: On Thu, Jul 16, 2015 at 3:19 AM, Tanu Kaskinen tanu.kaski...@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.s...@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). -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Thu, Jul 16, 2015 at 11:13 AM, Tanu Kaskinen tanu.kaski...@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.kaski...@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.s...@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. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Thu, 2015-07-16 at 11:21 -0700, Christopher Larson wrote: On Thu, Jul 16, 2015 at 11:13 AM, Tanu Kaskinen tanu.kaski...@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.kaski...@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.s...@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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
Hi,
I am not sure which is the behavior with those paths right now and how
it should be.
I just checked this:
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path
So, it seems according to documentation that system services should be
installed under /usr/lib/systemd/system, but currently they are
installed in /lib/systemd/system in my generated image. Is that a
expected behaviour? Shouldn't we try to follow documentation? I see
that sometimes /lib/systemd/system path is appended to the dirs in
systemdsystemunitpath, but it's not stated in the documentation,
that's a bit strange.
For user services, /usr/lib/systemd/user is already being used as
stated in docs.
Now, when multilib comes in, I get lost. If I understand correctly,
with multilib enabled we have too /lib64 and /usr/lib64. Are then
systemd service files suppoused to be installed in /usr/lib/systemd/
or in /usr/lib64/systemd/ ? If I undersood correctly your comment you
meant they should still be going into /usr/lib/systemd right?
Now, talking about bitbake.conf. I see there's already a line with the
following:
export systemd_unitdir = /lib/systemd
So, apart from your nonarch issue, I think it would also be a good
idea to split systemd_unitdir into system and user, as done by
provided pc in systemd (src/core/systemd.pc.in):
1- If still want system services to be in /lib and user services to be
in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
2- If you want both in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
Pau
2015-07-11 0:36 GMT+02:00 Burton, Ross ross.bur...@intel.com:
On 10 July 2015 at 15:04, Pau Espin Pedrol pau.es...@aweurope.be wrote:
+FILES_${PN}-server = ${bindir}/pulseaudio ${bindir}/start-*
${sysconfdir} ${bindir}/pactl */udev/rules.d/*.rules
${libdir}/systemd/user/*
That's going to break in multiarch builds, ie systemd units go into
$prefix/lib even if $libdir is $prefix/lib64.
(looks like we should add nonarch_libdir to bitbake.conf to codify this)
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Mon, Jul 13, 2015 at 3:23 AM, Pau Espin Pedrol pespin.s...@gmail.com
wrote:
I am not sure which is the behavior with those paths right now and how
it should be.
I just checked this:
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path
So, it seems according to documentation that system services should be
installed under /usr/lib/systemd/system, but currently they are
installed in /lib/systemd/system in my generated image. Is that a
expected behaviour? Shouldn't we try to follow documentation? I see
that sometimes /lib/systemd/system path is appended to the dirs in
systemdsystemunitpath, but it's not stated in the documentation,
that's a bit strange.
Depends on the distro. Ubuntu, for example, uses /lib/systemd.
For user services, /usr/lib/systemd/user is already being used as
stated in docs.
Now, when multilib comes in, I get lost. If I understand correctly,
with multilib enabled we have too /lib64 and /usr/lib64. Are then
systemd service files suppoused to be installed in /usr/lib/systemd/
or in /usr/lib64/systemd/ ? If I undersood correctly your comment you
meant they should still be going into /usr/lib/systemd right?
Yes, we don’t want arch-independent files going into arch-specific dirs.
Now, talking about bitbake.conf. I see there's already a line with the
following:
export systemd_unitdir = /lib/systemd
So, apart from your nonarch issue, I think it would also be a good
idea to split systemd_unitdir into system and user, as done by
provided pc in systemd (src/core/systemd.pc.in):
1- If still want system services to be in /lib and user services to be
in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
2- If you want both in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
I don’t really see why one would want some of their service files in one
libdir and the rest in another. Is there a reason to not just obey
systemd_unitdir in pulseaudio?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On Mon, Jul 13, 2015 at 9:17 AM, Pau Espin Pedrol pespin.s...@gmail.com
wrote:
Because they are actually a different type of service files (system vs
user) and they are handled in a different way by systemd. For
instance, if you check the list of paths in which systemd looks for
services, you can see that for system services it actually checks
/lib/systemd/system, but it doesn't for user ones
(/usr/lib/systemd/user):
In systemd, src/shared/path-lookup.c:
/* For the user units we include share/ in the search
* path in order to comply with the XDG basedir spec.
* For the system stuff we avoid such nonsense. OTOH
* we include /lib in the search path for the system
* stuff but avoid it for user stuff. */
if (running_as == MANAGER_USER) {
if (personal)
unit_path = user_dirs(generator,
generator_early, generator_late);
else
unit_path = strv_new(
/* If you modify this you also
want to modify
* systemduserunitpath= in
systemd.pc.in, and
* the arrays in user_dirs()
above! */
STRV_IFNOTNULL(generator_early),
USER_CONFIG_UNIT_PATH,
/etc/systemd/user,
/run/systemd/user,
STRV_IFNOTNULL(generator),
/usr/local/lib/systemd/user,
/usr/local/share/systemd/user,
USER_DATA_UNIT_PATH,
/usr/lib/systemd/user,
/usr/share/systemd/user,
STRV_IFNOTNULL(generator_late),
NULL);
} else
unit_path = strv_new(
/* If you modify this you also want to
modify
* systemdsystemunitpath= in systemd.pc.in!
*/
STRV_IFNOTNULL(generator_early),
SYSTEM_CONFIG_UNIT_PATH,
/etc/systemd/system,
/run/systemd/system,
STRV_IFNOTNULL(generator),
/usr/local/lib/systemd/system,
SYSTEM_DATA_UNIT_PATH,
/usr/lib/systemd/system,
#ifdef HAVE_SPLIT_USR
/lib/systemd/system,
#endif
STRV_IFNOTNULL(generator_late),
NULL);
And also in systemd, src/core/systemd.pc.in:
systemdsystemunitpath=${systemdsystemconfdir}:/etc/systemd/system:/run/systemd/system:/usr/local/lib/systemd/system:${systemdsystemunitdir}:/usr/lib/systemd/system:/lib/systemd/system
systemduserunitpath=${systemduserconfdir}:/etc/systemd/user:/run/systemd/user:/usr/local/lib/systemd/user:/usr/local/share/systemd/user:${systemduserunitdir}:/usr/lib/systemd/user:/usr/share/systemd/user
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.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
2015-07-13 17:51 GMT+02:00 Christopher Larson clar...@kergoth.com:
On Mon, Jul 13, 2015 at 3:23 AM, Pau Espin Pedrol pespin.s...@gmail.com
wrote:
I am not sure which is the behavior with those paths right now and how
it should be.
I just checked this:
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20Load%20Path
So, it seems according to documentation that system services should be
installed under /usr/lib/systemd/system, but currently they are
installed in /lib/systemd/system in my generated image. Is that a
expected behaviour? Shouldn't we try to follow documentation? I see
that sometimes /lib/systemd/system path is appended to the dirs in
systemdsystemunitpath, but it's not stated in the documentation,
that's a bit strange.
Depends on the distro. Ubuntu, for example, uses /lib/systemd.
For user services, /usr/lib/systemd/user is already being used as
stated in docs.
Now, when multilib comes in, I get lost. If I understand correctly,
with multilib enabled we have too /lib64 and /usr/lib64. Are then
systemd service files suppoused to be installed in /usr/lib/systemd/
or in /usr/lib64/systemd/ ? If I undersood correctly your comment you
meant they should still be going into /usr/lib/systemd right?
Yes, we don’t want arch-independent files going into arch-specific dirs.
Now, talking about bitbake.conf. I see there's already a line with the
following:
export systemd_unitdir = /lib/systemd
So, apart from your nonarch issue, I think it would also be a good
idea to split systemd_unitdir into system and user, as done by
provided pc in systemd (src/core/systemd.pc.in):
1- If still want system services to be in /lib and user services to be
in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_base_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
2- If you want both in /usr/lib:
export nonarch_libdir = ${prefix}/lib
export systemd_system_unitdir = ${nonarch_libdir}/systemd/system
export systemd_user_unitdir = ${nonarch_libdir}/systemd/user
or
export systemd_system_unitdir = ${nonarch_libdir}/systemd
export systemd_user_unitdir = ${nonarch_libdir}/systemd
I don’t really see why one would want some of their service files in one
libdir and the rest in another. Is there a reason to not just obey
systemd_unitdir in pulseaudio?
Because they are actually a different type of service files (system vs
user) and they are handled in a different way by systemd. For
instance, if you check the list of paths in which systemd looks for
services, you can see that for system services it actually checks
/lib/systemd/system, but it doesn't for user ones
(/usr/lib/systemd/user):
In systemd, src/shared/path-lookup.c:
/* For the user units we include share/ in the search
* path in order to comply with the XDG basedir spec.
* For the system stuff we avoid such nonsense. OTOH
* we include /lib in the search path for the system
* stuff but avoid it for user stuff. */
if (running_as == MANAGER_USER) {
if (personal)
unit_path = user_dirs(generator,
generator_early, generator_late);
else
unit_path = strv_new(
/* If you modify this you also
want to modify
* systemduserunitpath= in
systemd.pc.in, and
* the arrays in user_dirs() above! */
STRV_IFNOTNULL(generator_early),
USER_CONFIG_UNIT_PATH,
/etc/systemd/user,
/run/systemd/user,
STRV_IFNOTNULL(generator),
/usr/local/lib/systemd/user,
/usr/local/share/systemd/user,
USER_DATA_UNIT_PATH,
/usr/lib/systemd/user,
/usr/share/systemd/user,
STRV_IFNOTNULL(generator_late),
NULL);
} else
unit_path = strv_new(
/* If you modify this you also want to modify
* systemdsystemunitpath= in systemd.pc.in! */
STRV_IFNOTNULL(generator_early),
SYSTEM_CONFIG_UNIT_PATH,
/etc/systemd/system,
Re: [OE-core] [PATCH v2] pulseaudio: add systemd to PACKAGECONFIG if enabled in DISTRO_FEATURES
On 10 July 2015 at 15:04, Pau Espin Pedrol pau.es...@aweurope.be wrote:
+FILES_${PN}-server = ${bindir}/pulseaudio ${bindir}/start-*
${sysconfdir} ${bindir}/pactl */udev/rules.d/*.rules
${libdir}/systemd/user/*
That's going to break in multiarch builds, ie systemd units go into
$prefix/lib even if $libdir is $prefix/lib64.
(looks like we should add nonarch_libdir to bitbake.conf to codify this)
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
