Fw: Need some thoughts on systemd service file

[Patrick Williams]

Vishwa,

A few suggestions on your commit:

1. I see you put the files into .../network/files/ and moved them from
.../network/network/ .  Why is that?

2. 'inherit obmc-phosphor-systemd' causes your recipe to import
obmc-phosphor-systemd.bbclass.  This file has:
====
inherit systemd

SYSTEMD_SERVICE_${PN} = "${BPN}.service"
SRC_URI += " \
    file://${BPN}.service \
    "

do_install_append() {
    # install systemd unit files
    install -d ${D}${systemd_unitdir}/system
    install -m 0644 ${WORKDIR}/${BPN}.service ${D}${systemd_unitdir}/system
}
=====
This means a few things...
    a. By setting SYSTEMD_SERVICE_${PN} += "network.service", you're
       actually getting network.service added twice.
    b. network.service will be installed by this do_install_append
       snippet, but network-update-dns.service will not.  I think you
       need to 'install' it.
    c. I'm surprised we don't 'install' everything in
       SYSTEMD_SERVICE_${PN} automatically or in this .bbclass.  Maybe
       Brad can comment on why it is set up this way.

3. Before you made your change are we sure 'network.service' was
working?  Hopefully someone has previously tested this but there is
always the possibility that systemd is confused by 'network.service' vs
'network.target'.  Maybe 'network' is effectively a reserved word.

4. There is no advantage to setting SYSTEMD_AUTO_ENABLE because it is
already defaulted to 'enable'.

On Thu, Jun 16, 2016 at 11:11:00PM +0530, Vishwanatha Subbanna wrote:
> 
> 
> hello Team,
> 
> So here is what I am trying to do with :
> https://github.com/vishwabmc/openbmc/commit/f28651bb92bc7af6b503c9ca07aa8d76a3f0660c
> 
> 1/. Point bb to the git repo with commit #
> c69c3d30fd7d5fd04ba990788b6d75b19f275fc8 that introduced netman_watch_dns
> binary
> 2/. Create 2 .service files inside
> meta-phosphor/common/recipes-phosphor/network/files/ --> network.service
> and network-update-dns.service
> 3/  Make necessary changes to bitbake file so systemd can enable the
> services and start at boot.
> 4/. Build a Palmetto image ( or qemu too ) and copy 'em over to tftpserver
> ( /tftpboot/cuImage_vishwa_1 and /tftpboot/initrd_vishwa_1 )
> 5/. reboot palmetto and run netboot to new image.
> 
> I expected that the netman.py ( which is part of network.service ) and
> netman_watch_dns ( part of network-update-dns.service ) would get auto
> started but they did *not* start and I need some thoughts on why this may
> be happening.
> 
> https://lists.yoctoproject.org/pipermail/yocto/2015-April/024470.html
> ( Someone else also had same issue )
> 
> What is that I am seeing :
> 
> 1/. I see these 2 files are actually inside /lib/systemd/system/network
> Palmetto in as expected --> Good
> 2/. Services not started
> 3/. systemctl status network shows that its disabled. Same for update-dns.
> 4/. I see systemctl status skeleton displays everything is running
> 4.1/ Removing the Requires= and After= in network.service and booting to
> that changed image still does not help.
> 5/. Manual start using systemctl start network -and/or- systemctl start
> network-update-dns does everything okay and starts the expected services.
> 6/. No error seen in journal
> 
> Thanks
> 
> -------------------------------------------------------------------------------------
> 
> Thanks and Regards,
> Vishwanath.
> Advisory Software Engineer,
> Power Firmware Development,
> Systems &Technology Lab,
> MG2-6F-255 , Manyata Embassy Business Park,
> Bangalore , KA , 560045
> Ph: +91-80-46678255
> E-mail: vishwanath at in.ibm.com
> ----------------------------------------------------------------------------------
> 

> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc


-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160616/16f46f27/attachment.sig>