Patchwork [RFC,0/9] hybrid systemd/sysvinit

login
register
mail settings
Submitter Ross Burton
Date March 11, 2013, 8:07 p.m.
Message ID <cover.1363031776.git.ross.burton@intel.com>
Download mbox
Permalink /patch/45981/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib ross/systemd

Comments

Ross Burton - March 11, 2013, 8:07 p.m.
Hi,

This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
Packages will be built with both init scripts, and some daemons will be linking
to libsystemd-daemon so that will be pulled in to sysvinit images.

The init manager used at image construction time is DISTRO_FEATURES_INITMAN
(maybe this should be renamed) and that value is also backfilled into
DISTRO_FEATURES.

The key change is that systemd.bbclass only recommends systemd, and will check
that there's a systemctl binary before calling it - this allows packages built
like this to be installed on a systemd-free image.

This is very much a RFC, I've done some basic testing but between illness and
having to prepare for a presentation at this conference I've not been able to
test it as much as I'd hoped.  Review and testing very much appreciated.

Some metrics: adding the systemd feature but still using sysvinit when building
the image results in just libsystemd-daemon and the service files being added to
the image, with a negliable size increase.

Ross

The following changes since commit 1fd5b960dd36458b7b829f9094df18cd8b5ac201:

  systemd: remove libsystemd-daemon linkage in libudev (2013-03-11 10:59:54 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ross/systemd

for you to fetch changes up to ba7c15ae47ace8a15d97b4c58d2aa5b2ebb4c47a:

  default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES (2013-03-11 12:17:49 -0700)

----------------------------------------------------------------
Radu Moisan (1):
      busybox: add systemd enabling for syslog and klogd

Ross Burton (8):
      systemd: merge udev-systemd into udev
      systemd: make xz support (compressed journal) optional
      default-providers: change udev selection logic
      update-rcd.bbclass: handle both sysvinit and systemd features being present
      systemd: allow postinsts to run without systemd being present
      systemd: add udev init script for hybrid sysvinit/systemd usage
      update-rc.d/systemd: change communication variable name
      default-distrovars: don't add DISTRO_FEATURES_INITMAN to DISTRO_FEATURES

 meta/classes/systemd.bbclass                       |   37 ++++---
 meta/classes/update-rc.d.bbclass                   |    7 +-
 meta/conf/distro/include/default-distrovars.inc    |    2 +-
 meta/conf/distro/include/default-providers.inc     |    2 +-
 meta/recipes-core/busybox/busybox.inc              |   17 +++-
 meta/recipes-core/busybox/busybox_1.20.2.bb        |    2 +
 .../busybox/files/busybox-klogd.service.in         |    8 ++
 .../busybox/files/busybox-syslog.service.in        |   13 +++
 .../packagegroups/packagegroup-core-boot.bb        |    4 +-
 meta/recipes-core/systemd/systemd/init             |  101 ++++++++++++++++++++
 meta/recipes-core/systemd/systemd_197.bb           |   26 +++--
 11 files changed, 184 insertions(+), 35 deletions(-)
 create mode 100644 meta/recipes-core/busybox/files/busybox-klogd.service.in
 create mode 100644 meta/recipes-core/busybox/files/busybox-syslog.service.in
 create mode 100644 meta/recipes-core/systemd/systemd/init

Radu Moisan (1):
  busybox: add systemd enabling for syslog and klogd

Ross Burton (8):
  systemd: merge udev-systemd into udev
  systemd: make xz support (compressed journal) optional
  default-providers: change udev selection logic
  update-rcd.bbclass: handle both sysvinit and systemd features being
    present
  systemd: allow postinsts to run without systemd being present
  systemd: add udev init script for hybrid sysvinit/systemd usage
  update-rc.d/systemd: change communication variable name
  default-distrovars: don't add DISTRO_FEATURES_INITMAN to
    DISTRO_FEATURES

 meta/classes/systemd.bbclass                       |   37 ++++---
 meta/classes/update-rc.d.bbclass                   |    7 +-
 meta/conf/distro/include/default-distrovars.inc    |    2 +-
 meta/conf/distro/include/default-providers.inc     |    2 +-
 meta/recipes-core/busybox/busybox.inc              |   17 +++-
 meta/recipes-core/busybox/busybox_1.20.2.bb        |    2 +
 .../busybox/files/busybox-klogd.service.in         |    8 ++
 .../busybox/files/busybox-syslog.service.in        |   13 +++
 .../packagegroups/packagegroup-core-boot.bb        |    4 +-
 meta/recipes-core/systemd/systemd/init             |  101 ++++++++++++++++++++
 meta/recipes-core/systemd/systemd_197.bb           |   26 +++--
 11 files changed, 184 insertions(+), 35 deletions(-)
 create mode 100644 meta/recipes-core/busybox/files/busybox-klogd.service.in
 create mode 100644 meta/recipes-core/busybox/files/busybox-syslog.service.in
 create mode 100644 meta/recipes-core/systemd/systemd/init
Ross Burton - March 11, 2013, 9:37 p.m.
On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
> Packages will be built with both init scripts, and some daemons will be linking
> to libsystemd-daemon so that will be pulled in to sysvinit images.

Regarding the upgrade path, Richard/Paul/myself discussed this over
lunch and proposed that oe-core could gain an include file for distro
configuration that basically injects the backward compatibility
dependencies.  So for meta-systemd, it would inject
replaces/provides/conflicts for each of the packages in meta-systemd.
This would isolate the dependencies into a single location, and be
opt-in for distros that previously shipped meta-systemd.  Hopefully
the implementation of this is obvious, and patches to implement this
are welcome.

Ross
Otavio Salvador - March 11, 2013, 9:47 p.m.
On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
>> Packages will be built with both init scripts, and some daemons will be linking
>> to libsystemd-daemon so that will be pulled in to sysvinit images.
>
> Regarding the upgrade path, Richard/Paul/myself discussed this over
> lunch and proposed that oe-core could gain an include file for distro
> configuration that basically injects the backward compatibility
> dependencies.  So for meta-systemd, it would inject
> replaces/provides/conflicts for each of the packages in meta-systemd.
> This would isolate the dependencies into a single location, and be
> opt-in for distros that previously shipped meta-systemd.  Hopefully
> the implementation of this is obvious, and patches to implement this
> are welcome.

I personally prefer to still use meta-oe systemd class and keep the
possibility to product images with choosen init system. I think Martin
will also prefer it.
Ross Burton - March 11, 2013, 9:58 p.m.
Hi,

On 11 March 2013 14:47, Otavio Salvador <otavio@ossystems.com.br> wrote:
> I personally prefer to still use meta-oe systemd class and keep the
> possibility to product images with choosen init system. I think Martin
> will also prefer it.

I'd love Martin to speak for himself in this thread.

The big difference between meta-systemd and this series is that if you
enable both, you'll get a few service files in the sysvinit images and
probably libsystemd-daemon.  In total we're talking about a 50K
increase here which is for practical purposes negligible.

Are you objecting to the redundant service files (which you could
remove in a image construction hook, along with anything else that can
be wiped when you need to save every byte), or something else?

Ross
Khem Raj - March 11, 2013, 10:49 p.m.
On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:

> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
>>> Packages will be built with both init scripts, and some daemons will be linking
>>> to libsystemd-daemon so that will be pulled in to sysvinit images.
>> 
>> Regarding the upgrade path, Richard/Paul/myself discussed this over
>> lunch and proposed that oe-core could gain an include file for distro
>> configuration that basically injects the backward compatibility
>> dependencies.  So for meta-systemd, it would inject
>> replaces/provides/conflicts for each of the packages in meta-systemd.
>> This would isolate the dependencies into a single location, and be
>> opt-in for distros that previously shipped meta-systemd.  Hopefully
>> the implementation of this is obvious, and patches to implement this
>> are welcome.
> 
> I personally prefer to still use meta-oe systemd class and keep the
> possibility to product images with choosen init system. I think Martin
> will also prefer it.

using different init manager is a separate problem than what Ross tried to address here isn't it ?
I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so
for me I could easily accept a different solution for 1.4

> 
> -- 
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - March 11, 2013, 11:21 p.m.
On 11 March 2013 15:49, Khem Raj <raj.khem@gmail.com> wrote:
> using different init manager is a separate problem than what Ross tried to address here isn't it ?

This series lets you do DISTRO_FEATURES="systemd sysvinit" and it will
build support for both in the packages, and then based on
DISTRO_FEATURES_INITMAN it will build different images.

Ross
Koen Kooi - March 12, 2013, 7:42 a.m.
Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:

> 
> On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
>> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
>>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
>>>> Packages will be built with both init scripts, and some daemons will be linking
>>>> to libsystemd-daemon so that will be pulled in to sysvinit images.
>>> 
>>> Regarding the upgrade path, Richard/Paul/myself discussed this over
>>> lunch and proposed that oe-core could gain an include file for distro
>>> configuration that basically injects the backward compatibility
>>> dependencies.  So for meta-systemd, it would inject
>>> replaces/provides/conflicts for each of the packages in meta-systemd.
>>> This would isolate the dependencies into a single location, and be
>>> opt-in for distros that previously shipped meta-systemd.  Hopefully
>>> the implementation of this is obvious, and patches to implement this
>>> are welcome.
>> 
>> I personally prefer to still use meta-oe systemd class and keep the
>> possibility to product images with choosen init system. I think Martin
>> will also prefer it.
> 
> using different init manager is a separate problem than what Ross tried to address here isn't it ?
> I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so
> for me I could easily accept a different solution for 1.4

Upgrading between 1.3 and 1.4 is already impossible for non-systemd related reasons. But that shouldn't be a reason to break upgrade paths for other things, so I'd very much like to see some attention to this for 1.5.
Koen Kooi - March 12, 2013, 7:42 a.m.
Op 12 mrt. 2013, om 00:21 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 11 March 2013 15:49, Khem Raj <raj.khem@gmail.com> wrote:
>> using different init manager is a separate problem than what Ross tried to address here isn't it ?
> 
> This series lets you do DISTRO_FEATURES="systemd sysvinit" and it will
> build support for both in the packages, and then based on
> DISTRO_FEATURES_INITMAN it will build different images.

Isn't DISTRO_FEATURES_INITMAN more like an IMAGE_FEATURE now?
Richard Purdie - March 12, 2013, 6:50 p.m.
On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote:
> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:
> 
> > 
> > On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> > 
> >> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote:
> >>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
> >>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
> >>>> Packages will be built with both init scripts, and some daemons will be linking
> >>>> to libsystemd-daemon so that will be pulled in to sysvinit images.
> >>> 
> >>> Regarding the upgrade path, Richard/Paul/myself discussed this over
> >>> lunch and proposed that oe-core could gain an include file for distro
> >>> configuration that basically injects the backward compatibility
> >>> dependencies.  So for meta-systemd, it would inject
> >>> replaces/provides/conflicts for each of the packages in meta-systemd.
> >>> This would isolate the dependencies into a single location, and be
> >>> opt-in for distros that previously shipped meta-systemd.  Hopefully
> >>> the implementation of this is obvious, and patches to implement this
> >>> are welcome.
> >> 
> >> I personally prefer to still use meta-oe systemd class and keep the
> >> possibility to product images with choosen init system. I think Martin
> >> will also prefer it.
> > 
> > using different init manager is a separate problem than what Ross tried to address here isn't it ?
> > I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so
> > for me I could easily accept a different solution for 1.4
> 
> Upgrading between 1.3 and 1.4 is already impossible for non-systemd
> related reasons.

Which reasons?

Cheers,

Richard
Ross Burton - March 12, 2013, 8:18 p.m.
On 12 March 2013 00:42, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Isn't DISTRO_FEATURES_INITMAN more like an IMAGE_FEATURE now?

In a sense - it populates a distro feature though a backfill and is
used when constructing an image, so if you explicitly set
DISTRO_FEATURES to include both then swapping this will change the
image.

As I said, it should probably be renamed.  Any suggestions?

Ross
Koen Kooi - March 13, 2013, 9:09 a.m.
Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote:
>> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:
>> 
>>> 
>>> On Mar 11, 2013, at 2:47 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>> 
>>>> On Mon, Mar 11, 2013 at 6:37 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>>>> On 11 March 2013 13:07, Ross Burton <ross.burton@intel.com> wrote:
>>>>>> This series allows you to have both sysvinit and systemd in DISTRO_FEATURES.
>>>>>> Packages will be built with both init scripts, and some daemons will be linking
>>>>>> to libsystemd-daemon so that will be pulled in to sysvinit images.
>>>>> 
>>>>> Regarding the upgrade path, Richard/Paul/myself discussed this over
>>>>> lunch and proposed that oe-core could gain an include file for distro
>>>>> configuration that basically injects the backward compatibility
>>>>> dependencies.  So for meta-systemd, it would inject
>>>>> replaces/provides/conflicts for each of the packages in meta-systemd.
>>>>> This would isolate the dependencies into a single location, and be
>>>>> opt-in for distros that previously shipped meta-systemd.  Hopefully
>>>>> the implementation of this is obvious, and patches to implement this
>>>>> are welcome.
>>>> 
>>>> I personally prefer to still use meta-oe systemd class and keep the
>>>> possibility to product images with choosen init system. I think Martin
>>>> will also prefer it.
>>> 
>>> using different init manager is a separate problem than what Ross tried to address here isn't it ?
>>> I personally don't have a use case where I would upgrade live from 1.3 to 1.4 so
>>> for me I could easily accept a different solution for 1.4
>> 
>> Upgrading between 1.3 and 1.4 is already impossible for non-systemd
>> related reasons.
> 
> Which reasons?

Warning, handwaving ahead: Renamed packages, differently split packages et cetera.
Richard Purdie - March 13, 2013, 7:18 p.m.
On Wed, 2013-03-13 at 10:09 +0100, Koen Kooi wrote:
> Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> > On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote:
> >> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:
> >> Upgrading between 1.3 and 1.4 is already impossible for non-systemd
> >> related reasons.
> > 
> > Which reasons?
> 
> Warning, handwaving ahead: Renamed packages, differently split packages et cetera.

I thought we'd put Conflicts/Provides and other pieces in place to try
and avoid this? If there are issues, I'm open to patches which help
address the problems.

Cheers,

Richard
Martin Jansa - March 13, 2013, 10:09 p.m.
On Wed, Mar 13, 2013 at 07:18:39PM +0000, Richard Purdie wrote:
> On Wed, 2013-03-13 at 10:09 +0100, Koen Kooi wrote:
> > Op 12 mrt. 2013, om 19:50 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> > > On Tue, 2013-03-12 at 08:42 +0100, Koen Kooi wrote:
> > >> Op 11 mrt. 2013, om 23:49 heeft Khem Raj <raj.khem@gmail.com> het volgende geschreven:
> > >> Upgrading between 1.3 and 1.4 is already impossible for non-systemd
> > >> related reasons.
> > > 
> > > Which reasons?
> > 
> > Warning, handwaving ahead: Renamed packages, differently split packages et cetera.
> 
> I thought we'd put Conflicts/Provides and other pieces in place to try
> and avoid this? If there are issues, I'm open to patches which help
> address the problems.

I try to report such issues as soon as they are introduced to developer
who introduced them, but quite often those emails got no reply and issue
is forgotten.

I know I should report them in bugzilla, but I usually use oe-commits
list to find what changed since my last successful opkg upgrade and it's
faster to just reply there then to create new bug report.

Most of those issues would be detected by developers if they build with
buildhistory enabled and do upgrade on target device.