systemd services in the rootfs

systemd services in the rootfs

[Florin Sarbu]

Hi all,
following the transition of the systemd.bbclass from meta-openembedded 
to oe-core, I stumbled upon on what seems to me a missing feature that 
has not been brought along in the new systemd.bbclass in oe-core. Seems 
that if one does not explicitly specify the inclusion of the packages 
containing the systemd services in a packagegroup or image recipe or use 
some other mechanism that will determine the addition of these packages 
in the final rootfs, then the root filesystem will not contain the 
systemd services. Even though DISTRO_FEATURES_INITMAN="systemd" is set. 
The meta-openembedded systemd.bbclass, needed no additional adding of 
the systemd related packages, just RRECOMMENDED and things worked as 
expected. Shouldn't the DISTRO_FEATURES_INITMAN do just that? Is it 
something that still needs to be done on the systemd.bbclass or would 
you suggest that from now on we will have to manually add the systemd 
packages in packagegroups, image recipes etc?

Thank you,
Florin

Re: systemd services in the rootfs

[Radu Moisan]

On 02/13/2013 05:33 PM, Florin Sarbu wrote:
> Hi all,
> following the transition of the systemd.bbclass from meta-openembedded 
> to oe-core, I stumbled upon on what seems to me a missing feature that 
> has not been brought along in the new systemd.bbclass in oe-core. 
> Seems that if one does not explicitly specify the inclusion of the 
> packages containing the systemd services in a packagegroup or image 
> recipe or use some other mechanism that will determine the addition of 
> these packages in the final rootfs, then the root filesystem will not 
> contain the systemd services. Even though 
> DISTRO_FEATURES_INITMAN="systemd" is set. The meta-openembedded 
> systemd.bbclass, needed no additional adding of the systemd related 
> packages, just RRECOMMENDED and things worked as expected. Shouldn't 
> the DISTRO_FEATURES_INITMAN do just that? Is it something that still 
> needs to be done on the systemd.bbclass or would you suggest that from 
> now on we will have to manually add the systemd packages in 
> packagegroups, image recipes etc?
>

Each recipe should install it's service files in the appropriate 
location, like ${D}${systemd-unitdir}/system (check out searchpaths in 
systemd.bbclass)

For reference you can check on my branch enabling patches
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-ross&id=38dfb4ec00aa87ab20065de7b391572f19679ca8

Radu

Re: systemd services in the rootfs

[Florin Sarbu]

The issue I was referring to was that the individual packages (that 
contain the systemd service files) generated from various recipes, do 
not end up in the rootfs solely by having them declared in the 
SYSTEMD_PACKAGES and having DISTRO_FEATURES_INITMAN ="systemd". You need 
now to explicitly add these ${PN}-systemd (or whatever name you choose 
for the packages that will hold the systemd services) in some 
packagegroups or image recipes to have them in the rootfs. It is not a 
question of where to have them in the rootfs, but rather to have them 
added in the do_rootfs stage.

Hope I cleared things up a little better now.

Thanks,
Florin

On 02/14/2013 10:47 AM, Radu Moisan wrote:
>
> On 02/13/2013 05:33 PM, Florin Sarbu wrote:
>> Hi all,
>> following the transition of the systemd.bbclass from 
>> meta-openembedded to oe-core, I stumbled upon on what seems to me a 
>> missing feature that has not been brought along in the new 
>> systemd.bbclass in oe-core. Seems that if one does not explicitly 
>> specify the inclusion of the packages containing the systemd services 
>> in a packagegroup or image recipe or use some other mechanism that 
>> will determine the addition of these packages in the final rootfs, 
>> then the root filesystem will not contain the systemd services. Even 
>> though DISTRO_FEATURES_INITMAN="systemd" is set. The 
>> meta-openembedded systemd.bbclass, needed no additional adding of the 
>> systemd related packages, just RRECOMMENDED and things worked as 
>> expected. Shouldn't the DISTRO_FEATURES_INITMAN do just that? Is it 
>> something that still needs to be done on the systemd.bbclass or would 
>> you suggest that from now on we will have to manually add the systemd 
>> packages in packagegroups, image recipes etc?
>>
>
> Each recipe should install it's service files in the appropriate 
> location, like ${D}${systemd-unitdir}/system (check out searchpaths in 
> systemd.bbclass)
>
> For reference you can check on my branch enabling patches
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-ross&id=38dfb4ec00aa87ab20065de7b391572f19679ca8 
>
>
> Radu
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: systemd services in the rootfs

[Burton, Ross]

On 14 February 2013 09:09, Florin Sarbu <florin.sarbu@windriver.com> wrote:
> The issue I was referring to was that the individual packages (that contain
> the systemd service files) generated from various recipes, do not end up in
> the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
> DISTRO_FEATURES_INITMAN ="systemd". You need now to explicitly add these
> ${PN}-systemd (or whatever name you choose for the packages that will hold
> the systemd services) in some packagegroups or image recipes to have them in
> the rootfs. It is not a question of where to have them in the rootfs, but
> rather to have them added in the do_rootfs stage.

Put the service files into the relevant package (i.e. $PN, instead of
into a separate package of their own.

This is different to how meta-systemd worked, because in oe-core
systemd is a DISTRO_FEATURE and not something you can decide at image
construction time.

Ross

Re: systemd services in the rootfs

[Florin Sarbu]

So choosing, for example ${PN} to hold the systemd services, and also 
choose to use sysvinit as the init manager, then I'd end up with a 
rootfs containing useless systemd services.
Then can someone detail what is SYSTEMD_PACKAGES used for? If it's only 
for adding the packages to PACKAGES, then it doesn't make too much sense 
to exist in my opinion, as it would just be an extra variable defined to 
do something that can be achieved without defining a extra variable.

Florin

On 02/14/2013 12:17 PM, Burton, Ross wrote:
> On 14 February 2013 09:09, Florin Sarbu <florin.sarbu@windriver.com> wrote:
>> The issue I was referring to was that the individual packages (that contain
>> the systemd service files) generated from various recipes, do not end up in
>> the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
>> DISTRO_FEATURES_INITMAN ="systemd". You need now to explicitly add these
>> ${PN}-systemd (or whatever name you choose for the packages that will hold
>> the systemd services) in some packagegroups or image recipes to have them in
>> the rootfs. It is not a question of where to have them in the rootfs, but
>> rather to have them added in the do_rootfs stage.
> Put the service files into the relevant package (i.e. $PN, instead of
> into a separate package of their own.
>
> This is different to how meta-systemd worked, because in oe-core
> systemd is a DISTRO_FEATURE and not something you can decide at image
> construction time.
>
> Ross

How to "implement" systemd

[Mike Looijmans]

So far i've been using good old initscripts for my systems. I want to 
try out systemd. Having zero experience with that, I just added 
"systemd" to the DISTRO_FEATURES and started a fresh  build. The build 
ran fine, but it produced something that still seems to be using 
initscripts, albeit that a few things stopped working (the network did 
not start, for example).

Is there some openembedded "guide" on what one has to do to actually use 
systemd? I've tried google, but because i don't have a clue what 
keywords to look for, I got only irrelevant results on various Linux 
distributions while searching with "oe-core initscripts to systemd" and 
variations on that theme.

Re: How to "implement" systemd

[Marcin Juszkiewicz]

W dniu 14.02.2013 13:35, Mike Looijmans pisze:
> So far i've been using good old initscripts for my systems. I want to
> try out systemd. Having zero experience with that, I just added
> "systemd" to the DISTRO_FEATURES and started a fresh  build. The build
> ran fine, but it produced something that still seems to be using
> initscripts, albeit that a few things stopped working (the network did
> not start, for example).

DISTRO_FEATURES_INITMAN = "systemd" is what you want.

Re: How to "implement" systemd

[Mike Looijmans]

On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote:
> W dniu 14.02.2013 13:35, Mike Looijmans pisze:
>> So far i've been using good old initscripts for my systems. I want to
>> try out systemd. Having zero experience with that, I just added
>> "systemd" to the DISTRO_FEATURES and started a fresh  build. The build
>> ran fine, but it produced something that still seems to be using
>> initscripts, albeit that a few things stopped working (the network did
>> not start, for example).
>
> DISTRO_FEATURES_INITMAN = "systemd" is what you want.

Sorry, I have to amend my original post.

DISTRO_FEATURES_INITMAN = "systemd"

is just what I did (added it to my distro .conf file), because from the 
source I gathered that that was the way to get it into DISTRO_FEATURES.

How can I check whether it's using systemd? I don't see any obvious 
difference in the rootfs, and I never saw any systemd package being 
built either.

Mike.

Re: How to "implement" systemd

[Mike Looijmans]

On 02/14/2013 01:57 PM, Mike Looijmans wrote:
> On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote:
>> W dniu 14.02.2013 13:35, Mike Looijmans pisze:
>>> So far i've been using good old initscripts for my systems. I want to
>>> try out systemd. Having zero experience with that, I just added
>>> "systemd" to the DISTRO_FEATURES and started a fresh  build. The build
>>> ran fine, but it produced something that still seems to be using
>>> initscripts, albeit that a few things stopped working (the network did
>>> not start, for example).
>>
>> DISTRO_FEATURES_INITMAN = "systemd" is what you want.
>
> Sorry, I have to amend my original post.
>
> DISTRO_FEATURES_INITMAN = "systemd"
>
> is just what I did (added it to my distro .conf file), because from the
> source I gathered that that was the way to get it into DISTRO_FEATURES.
>
> How can I check whether it's using systemd? I don't see any obvious
> difference in the rootfs, and I never saw any systemd package being
> built either.

Ah, to (probably) answer my own question, there was a hidden
VIRTUAL-RUNTIME_init_manager = "sysvinit"
in my config chain, which was probably the cause. Running another build, 
and I've seen a systemd task being run now...

Re: systemd services in the rootfs

[Burton, Ross]

On 14 February 2013 12:32, Florin Sarbu <florin.sarbu@windriver.com> wrote:
> So choosing, for example ${PN} to hold the systemd services, and also choose
> to use sysvinit as the init manager, then I'd end up with a rootfs
> containing useless systemd services.

That would be a packaging bug.

The systemd class only does work if the systemd feature is enabled.
When installing service files manually, respect the systemd feature.

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=rmoisan/systemd-ross&id=d6a9fe2e980eb996c36712983b151b04774438df
is an example of systemd integration for dropbear that does the right
thing.

Ross

Re: How to "implement" systemd

[Mike Looijmans]

On 02/14/2013 02:42 PM, Mike Looijmans wrote:
> On 02/14/2013 01:57 PM, Mike Looijmans wrote:
>> On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote:
>>> W dniu 14.02.2013 13:35, Mike Looijmans pisze:
>>>> So far i've been using good old initscripts for my systems. I want to
>>>> try out systemd. Having zero experience with that, I just added
>>>> "systemd" to the DISTRO_FEATURES and started a fresh  build. The build
>>>> ran fine, but it produced something that still seems to be using
>>>> initscripts, albeit that a few things stopped working (the network did
>>>> not start, for example).
>>>
>>> DISTRO_FEATURES_INITMAN = "systemd" is what you want.
>>
>> Sorry, I have to amend my original post.
>>
>> DISTRO_FEATURES_INITMAN = "systemd"
>>
>> is just what I did (added it to my distro .conf file), because from the
>> source I gathered that that was the way to get it into DISTRO_FEATURES.
>>
>> How can I check whether it's using systemd? I don't see any obvious
>> difference in the rootfs, and I never saw any systemd package being
>> built either.
>
> Ah, to (probably) answer my own question, there was a hidden
> VIRTUAL-RUNTIME_init_manager = "sysvinit"
> in my config chain, which was probably the cause. Running another build,
> and I've seen a systemd task being run now...

That indeed "solved" the issue. However, the image doesn't get to a 
point that I can actually log in or do something useful, so I guess the 
default is still sysvinit for good reasons :)

Here's all the logging I get before it "dies":


systemd[1]: systemd 197 running in system mode. (-PAM -LIBWRAP -AUDIT 
-SELINUX +IMA +S
YSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ) 

Welcome to Linux! 

 

š���͕��m�]: Cannot add dependency job for unit display-manager.service, 
ignoring: Uni t
  display-manager.service failed to load: No such file or directory. See 
system logs an
          Expecting device dev-ttyPS0.device.....Wall Directory Watch.. 

[  OK  ] Reached target Remote File Systems. 

[  OK  ] Listening on /dev/initctl Compatibility Named Pipe. 

[  OK  ] Listening on Delayed Shutdown Socket.ility Named Pipe. 

[  OK  ] Listening on udev Kernel Socket.ests to Console Directory 
Watch..
[  OK  ] Listening on udev Control Socket.t. 

š���͕��m�]: Set up automount Arbitrary Executable File Formats File 
System Automount  P
[  OK  ] Reached target Swap. 

[  OK  ] Listening on Journal Socket. 

          Mounting Temporary Directory..... 

          Starting Remount Root and Kernel File Systems..... 

          Starting Load Kernel Modules...... 

EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) 

          Mounting Debug File System......