[yocto] Fwd: With my layer, Systemd not invoking my application at startup

[Vipin Nair]

Thanks a lot Saul for your valuable inputs on my problem.

I have tried inheriting from the useradd.bbclass and the USER add works
with both approach i.e by inheriting from useradd.bb class or manually
calling useradd.

But my main problem 'wherein the systemd does not invoke my service during
first boot ' is not getting resolved.

I have to run the pkg_posinst on the board, for the following two reasons :
 ---- I have to change the file ownership to the newly created user. If I
try to do this on board, it fails
----- I have to run some configuration scripts,which is required for my
service to startup. But this configuration script needs to be run only once
per installation, and so I don't want
to put is in the systemd unitfile.


Here is the brief of my recipe file( sorry, but I can not share the whole
recipe file)
------------------------------------------------------------------------------------------------------------------

DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'systemd-systemctl-native', '', d)}"


do_install() {
------------
------------
#if systemd configured
install -m 0755 -d ${D}/lib/systemd/system
cp ${WORKDIR}/${MA_BIN_DIR}/my_ser.service ${D}/lib/systemd/system/
------------
------------
}

pkg_preinst_${PN}() {
------------
------------

if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
systemctl --root=$D enable my_ser.service    # Have tried executing it only
on postinstall, but it does not help.
fi
------------
------------
}

pkg_postinst_${PN}() {
------------
------------
if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
systemctl --root=$D enable ma.service
fi
 if [ x"$D" = "x" ] ; then
 # Create group and user
groupadd test_grp
useradd -r -s /sbin/nologin -g  test_grp test_usr
 chown test_usr:test_grp /etc/test_folder/*
 if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
if [ "$1" == 1 ] || [ "$1" = 2 ] ; then  # only install and upgrade
scenario, not to exeute on 1st boot
systemctl daemon-reload
systemctl start my_ser.service
fi
else
exit 1
fi
}

And here is the Unit file for my service :
-------------------------------------------------------

[Unit]
Description=test service

[Service]
Type=forking
ExecStartPre=-/bin/mkdir -p /var/tmp/test_config_file
ExecStartPre=-/bin/chmod 777 /var/tmp/test_config_file
ExecStartPre=-/bin/chmod o+t /var/tmp/test_config_file
ExecStart=/opt/test_app start
ExecStop=/opt/test_app  stop
Type=forking
TimeoutStartSec=20
SendSIGKILL=no

[Install]
WantedBy=multi-user.target

Thanks
Vipin



On Wed, Jul 1, 2015 at 10:14 PM, Saul Wold <sgw at linux.intel.com> wrote:

> On 06/30/2015 08:35 PM, Vipin Nair wrote:
>
>> Hi All,
>>
>> I have  created a layer (my first layer) and have build it with WindRiver
>> media which uses Systemd for the startup services.
>>
>> As per my application need, I have to create a new user on the final image
>> and change the owner permissions of certain files to the new user.
>> Since I could not get it done on the build machine, I have written the
>> post
>> install script such that it gets executed on the  target board during the
>> 1st boot cycle
>> and from within the post install script I am creating the new user and
>> changing the file ownership. And this works.
>>
>> But the only problem I have now is that, even though I register my service
>> with Systemd at pre-install (or postinstall) section (using the systemctl
>> enable command)
>> my service is not getting launched by Systemd during the 1st boot. On
>> subsequent reboots, it invokes my service at boot up.
>>
>> As part of debugging I just modified my postinstall script, such that it
>> gets executed on the board (i.e without the exit 1)  and not executed on
>> the 1st boot. After that I see that
>> systemd invokes my service at boot up.  So I wonder if Systemd ignores the
>> services for which post-install is not invoked at build machine ?
>>
>> Now I am confused on how to solve this problem.
>>
>> Only 2 approaches comes to my mind :
>> 1) Run the postinstall on the board only (not on 1st boot)  - But with
>> this
>> (i.e running the postinstall section on board) I don't see the new user
>> creation happening and as a result it fails to change the file ownership.
>>
>> 2) Somehow force systemd to invoke my service at startup (even with
>> postinstall running during 1st boot)  - But I don't know what I have to do
>> to achieve this.
>>
>> Here is the brief of my recipe file :
>> -----------------------------------------------
>>
>> DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
>> 'systemd-systemctl-native', '', d)}"
>>
>>
>> do_install() {
>> ------------
>> ------------
>> #if systemd configured
>> install -m 0755 -d ${D}/lib/systemd/system
>> cp ${WORKDIR}/${MA_BIN_DIR}/my_ser.service ${D}/lib/systemd/system/
>> ------------
>> ------------
>> }
>>
>> pkg_preinst_${PN}() {
>> ------------
>> ------------
>>
>> if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
>> systemctl --root=$D enable my_ser.service    # Have tried executing it
>> only
>> on postinstall, but it does not help.
>> fi
>> ------------
>> ------------
>> }
>>
>> pkg_postinst_${PN}() {
>> ------------
>> ------------
>> if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
>> systemctl --root=$D enable ma.service
>> fi
>>   if [ x"$D" = "x" ] ; then
>>   # Create group and user
>> groupadd test_grp
>> useradd -r -s /sbin/nologin -g  test_grp test_usr
>>
>
> It appears you did not try to use the useradd bbclass here.
>
>    chown test_usr:test_grp /etc/test_folder/*
>>   if [  "$IS_SYSTEMD_CONFIGURED" = "yes" ] ; then
>> if [ "$1" == 1 ] || [ "$1" = 2 ] ; then  # only install and upgrade
>> scenario, not to exeute on 1st boot
>> systemctl daemon-reload
>> systemctl start my_ser.service
>> fi
>> else
>> exit 1
>> fi
>> }
>>
>> I am new to the yacto project and the layer approach. So kindly guide me
>> on
>> how to resolve this issue.
>>
>>  If you can send your full bb file, are you using the systemd bbclass as
> I suggested in a past email?
>
> Sau!
>
>
>
>  Also if this is not the right group to get help on this issue, please
>> suggest about the relevant group.
>>
>> Thanks
>> Vipin
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150702/d0118047/attachment.html>