[swupdate] [PATCH 3/3] [meta-swupdate] [v2,3/3] swupdate: Set service type to notify

[Hamza, Muhammad]

swupdate: Set service type to notify

In previous commit swupdate service type was set to 'exec'
however, swupdate has already implemented support for 'notify'
type. This commit updates the service type to 'notify'.

Signed-off-by: Muhammad Hamza <muhamma...@mentor.com>

diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate/swupdate.service
index c0253aa..7f8e966 100644
--- a/recipes-support/swupdate/swupdate/swupdate.service
+++ b/recipes-support/swupdate/swupdate/swupdate.service
@@ -4,7 +4,7 @@ Documentation=https://github.com/sbabic/swupdate
Documentation=https://sbabic.github.io/swupdate

[Service]
-Type=exec
+Type=notify
ExecStart=@LIBDIR@/swupdate/swupdate.sh
KillMode=mixed

[Stefano Babic]

Reviewed-by: Stefano Babic <sba...@denx.de>

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Stefano Babic]

On 13.06.22 10:44, Hamza, Muhammad wrote:

Applied to -master, -kirkstone, -honister, -dunfell, thanks !

[Johannes Schrimpf]

Hi,

Since the update, our swupdate service times out:

× swupdate.service - SWUpdate daemon

     Loaded: loaded (/lib/systemd/system/swupdate.service; enabled; vendor preset: enabled)

     Active: failed (Result: timeout) since Fri 2021-11-19 17:21:05 UTC; 9min ago

TriggeredBy: ● swupdate.socket

       Docs: https://github.com/sbabic/swupdate

             https://sbabic.github.io/swupdate

    Process: 357 ExecStart=/usr/lib/swupdate/swupdate.sh (code=exited, status=0/SUCCESS)

   Main PID: 357 (code=exited, status=0/SUCCESS)

Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running :  [network_initializer] : Main loop daemon

Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/swupdateprog

Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/sockinstctrl

Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running :  [start_swupdate_subprocess] : Started webserver with pid 386 and fd 10

Nov 19 17:19:35 blueye swupdate.sh[357]: [INFO ] : SWUPDATE running :  [start_mongoose] : Mongoose web server version 6.18 with pid 386 started on port(s) 8080 with web root [/www]

Nov 19 17:21:05 blueye systemd[1]: swupdate.service: start operation timed out. Terminating.

Nov 19 17:21:05 blueye systemd[1]: swupdate.service: Killing process 386 (swupdate) with signal SIGKILL.

Nov 19 17:21:05 blueye systemd[1]: swupdate.service: Failed with result 'timeout'.

Nov 19 17:21:05 blueye systemd[1]: swupdate.service: Unit process 386 (swupdate) remains running after unit stopped.

Nov 19 17:21:05 blueye systemd[1]: Failed to start SWUpdate daemon.

From the documentation, it seems that CONFIG_SYSTEMD needs to be activated for this to work. This was not done in our config but neither in the defconfig in meta-swupdate, so I suppose it will fail in the standard configuration as well.

https://github.com/sbabic/meta-swupdate/blob/554b97ac9970ccdb41408f2440cd48446534a7d7/recipes-support/swupdate/swupdate/defconfig#L16

A fast test activating the CONFIG_SYSTEMD flag and adding systemd to the recipe DEPENDS seemed to fix it for us. We use Honister in our setup.

Unfortunately, I don’t have a setup with only the standard layers, so I don’t have the possibility to prepare and test a patch for meta-swupdate without custom modifications at the moment.

Best regards

Johannes Schrimpf

[Stefano Babic]

Hi Johannes,

On 17.06.22 13:46, Johannes Schrimpf wrote:
> Hi,
>
> Since the update, our swupdate service times out:
>

> *×* swupdate.service - SWUpdate daemon

>      Loaded: loaded (/lib/systemd/system/swupdate.service; enabled;
> vendor preset: enabled)

>      Active: *failed* (Result: timeout) since Fri 2021-11-19 17:21:05
> UTC; 9min ago
> TriggeredBy: *●* swupdate.socket

>        Docs: https://github.com/sbabic/swupdate
>              https://sbabic.github.io/swupdate
>     Process: 357 ExecStart=/usr/lib/swupdate/swupdate.sh (code=exited,
> status=0/SUCCESS)
>    Main PID: 357 (code=exited, status=0/SUCCESS)
>
> Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running
> :  [network_initializer] : Main loop daemon
> Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running
> :  [listener_create] : creating socket at /tmp/swupdateprog
> Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running
> :  [listener_create] : creating socket at /tmp/sockinstctrl
> Nov 19 17:19:35 blueye swupdate.sh[357]: [TRACE] : SWUPDATE running
> :  [start_swupdate_subprocess] : Started webserver with pid 386 and fd 10
> Nov 19 17:19:35 blueye swupdate.sh[357]: [INFO ] : SWUPDATE running
> :  [start_mongoose] : Mongoose web server version 6.18 with pid 386
> started on port(s) 8080 with web root [/www]

> Nov 19 17:21:05 blueye systemd[1]: *swupdate.service: start operation
> timed out. Terminating.*
> Nov 19 17:21:05 blueye systemd[1]: *swupdate.service: Killing process
> 386 (swupdate) with signal SIGKILL.*
> Nov 19 17:21:05 blueye systemd[1]: *swupdate.service: Failed with result
> 'timeout'.*

> Nov 19 17:21:05 blueye systemd[1]: swupdate.service: Unit process 386
> (swupdate) remains running after unit stopped.

> Nov 19 17:21:05 blueye systemd[1]: *Failed to start SWUpdate daemon.*

>

>
> From the documentation, it seems that CONFIG_SYSTEMD needs to be
> activated for this to work.

It makes sense - systemd waits for the notification, and if
CONFIG_SYSTEMD is not on, SWUpdate does not send it.

> This was not done in our config but neither
> in the defconfig in meta-swupdate,

It is arguable if this should be set in meta-swupdate's defconfig. It
will break builds based on SystemV, for example. The defconfig in
meta-swupdate is just for reference, but it is thought that each project
sets its own - the defconfig in meta-swupdate has also no security
turned on, no signed images, etc.

> so I suppose it will fail in the
> standard configuration as well.
>
> https://github.com/sbabic/meta-swupdate/blob/554b97ac9970ccdb41408f2440cd48446534a7d7/recipes-support/swupdate/swupdate/defconfig#L16

...if systemd is the init manager, what meta-swupdate cannot know.

Probably it is worth to add this to the documentation, and that
CONFIG_SYSTEMD must be turned on.

>
> A fast test activating the CONFIG_SYSTEMD flag and adding systemd to the
> recipe DEPENDS seemed to fix it for us. We use Honister in our setup.

Ok

>
> Unfortunately, I don’t have a setup with only the standard layers, so I
> don’t have the possibility to prepare and test a patch for meta-swupdate
> without custom modifications at the moment.

Best regards,
Stefano

>
> Best regards
> Johannes Schrimpf
>
> On Tuesday, June 14, 2022 at 12:33:21 PM UTC+2 Stefano Babic wrote:
>
> On 13.06.22 10:44, Hamza, Muhammad wrote:
> > swupdate: Set service type to notify
> >
> > In previous commit swupdate service type was set to 'exec'
> > however, swupdate has already implemented support for 'notify'
> > type. This commit updates the service type to 'notify'.
> >
> > Signed-off-by: Muhammad Hamza <muhamma...@mentor.com>
> >
> > diff --git a/recipes-support/swupdate/swupdate/swupdate.service
> b/recipes-support/swupdate/swupdate/swupdate.service
> > index c0253aa..7f8e966 100644
> > --- a/recipes-support/swupdate/swupdate/swupdate.service
> > +++ b/recipes-support/swupdate/swupdate/swupdate.service
> > @@ -4,7 +4,7 @@ Documentation=https://github.com/sbabic/swupdate

> <https://github.com/sbabic/swupdate>
> > Documentation=https://sbabic.github.io/swupdate

> <https://sbabic.github.io/swupdate>
> >
> > [Service]
> > -Type=exec
> > +Type=notify
> > ExecStart=@LIBDIR@/swupdate/swupdate.sh
> > KillMode=mixed
> >
>
> Applied to -master, -kirkstone, -honister, -dunfell, thanks !
>
> Best regards,
> Stefano Babic
>
>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/325c3861-31d4-40ba-ae1f-1f12f9d15be1n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/325c3861-31d4-40ba-ae1f-1f12f9d15be1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johannes Schrimpf]

Hi Stefano,

I think it makes sense to make meta-swupdate consistent such that it will not lead to a failing service if used in the standard configuration.

It seems to me that you already are using inherit systemd in swupdate.inc, so you already have a dependency there, I think. If you want to address systems running systemV, my suggestion would be to use branches for both inherit, DEPENDS, and also to pick a defconfig, something like:

inherit ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','', d)}

or:

if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then

Some examples of recipes that use VIRTUAL-RUNTIME_init_manager and/or DISTRO_FEATURES to determine whether systemd or sysvinit is used:

https://github.com/yoctoproject/poky/blob/master/meta/recipes-graphics/wayland/weston_10.0.0.bb

https://git.yoctoproject.org/poky/plain/meta/recipes-core/busybox/busybox.inc

Best regards,

Johannes Schrimpf

[Stefano Babic]

Hi Johannes,

On 17.06.22 14:28, Johannes Schrimpf wrote:
> Hi Stefano,
>
> I think it makes sense to make meta-swupdate consistent such that it
> will not lead to a failing service if used in the standard configuration.
>
> It seems to me that you already are using inherit systemd in
> swupdate.inc, so you already have a dependency there, I think. If you
> want to address systems running systemV, my suggestion would be to use
> branches for both inherit, DEPENDS, and also to pick a defconfig,
> something like:
>
> inherit
> ${@bb.utils.contains('VIRTUAL-RUNTIME_init_manager','systemd','systemd','',
> d)}
>
> or:
>
> if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then
>

IMO it should be done on the config file, like it is done for DEPENDS.
If VIRTUAL-RUNTIME_init_manager is set to systemd, recipe should add
CONFIG_SYSTEMD to the configuration file, probably in do_configure()

Best regards,
Stefano

>
> Some examples of recipes that use VIRTUAL-RUNTIME_init_manager and/or
> DISTRO_FEATURES to determine whether systemd or sysvinit is used:
> https://github.com/yoctoproject/poky/blob/master/meta/recipes-graphics/wayland/weston_10.0.0.bb
> https://git.yoctoproject.org/poky/plain/meta/recipes-core/busybox/busybox.inc
>
> Best regards,
> Johannes Schrimpf
> On Friday, June 17, 2022 at 1:56:04 PM UTC+2 Stefano Babic wrote:
>
> Hi Johannes,
>
> On 17.06.22 13:46, Johannes Schrimpf wrote:
> > Hi,
> >
> > Since the update, our swupdate service times out:
> >
> > *×* swupdate.service - SWUpdate daemon
> >      Loaded: loaded (/lib/systemd/system/swupdate.service; enabled;
> > vendor preset: enabled)
> >      Active: *failed* (Result: timeout) since Fri 2021-11-19
> 17:21:05
> > UTC; 9min ago
> > TriggeredBy: *●* swupdate.socket
> >        Docs: https://github.com/sbabic/swupdate

> <https://github.com/sbabic/swupdate>
> > https://sbabic.github.io/swupdate

> <https://groups.google.com/d/msgid/swupdate/325c3861-31d4-40ba-ae1f-1f12f9d15be1n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/swupdate/325c3861-31d4-40ba-ae1f-1f12f9d15be1n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany

> Phone: +49-8142-66989-53 <tel:+49%208142%206698953> Fax:
> +49-8142-66989-80 <tel:+49%208142%206698980> Email: sba...@denx.de
> =====================================================================
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/swupdate/6199e27f-3596-46a0-a9c4-848e29a1dd7dn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/6199e27f-3596-46a0-a9c4-848e29a1dd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johannes Schrimpf]

Good idea to add it in do_configure. Sounds clean.

Best regards

Johannes

[Mickael Toumi]

Dear Johannes,

I am working on a Yocto Kirkstone build with SWUpdate. I have noticed you originally reported an issue with timeout last year (at the beginning of this post). I am facing a similar issue with timeout.

The few steps I took so far are:

1) Enabled support for systemd via bitbake -c menuconfig swupdate

2) Installed the systemd development header file on the Linux build machine via: sudo apt-get install libsystemd-dev. I don't think I have seen this clearly in the documentation as a requirement for systemd, maybe I have missed it. It is needed, otherwise compilation errors are showing up around swupdate.c using <systemd/sd-daemon.h>.

3) I have a dedicated recipe to build a release with SWUpdate enabled. I have set DEPENDS += "systemd" and followed the steps to use the Yocto class to build for A/B partition as opposed to a rescue image with ramfs.

Compilation goes through, the execution is still showing a timeout, the daemon is gone as you can see below:

root@pico-imx6ul:~# systemctl | grep swupdate
* swupdate.service                                                                                           loaded failed failed    SWUpdate daemon
  swupdate.socket                                                                                            loaded active listening SWUpdate socket listener

Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [INFO ] : SWUPDATE running :  [print_registered_handlers] :         preinstall
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [INFO ] : SWUPDATE running :  [print_registered_handlers] :         postinstall
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [TRACE] : SWUPDATE running :  [network_initializer] : Main loop daemon
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/swupdateprog
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/sockinstctrl
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [TRACE] : SWUPDATE running :  [start_swupdate_subprocess] : Started webserver with pid 194 and fd 10
Apr 17 03:10:17 pico-imx6ul swupdate.sh[180]: [INFO ] : SWUPDATE running :  [start_mongoose] : Mongoose web server version 7.8 with pid 194 started on [0.0.0.0:8080] with web root [/www]
Apr 17 03:11:46 pico-imx6ul systemd[1]: swupdate.service: start operation timed out. Terminating.
Apr 17 03:11:46 pico-imx6ul systemd[1]: swupdate.service: Failed with result 'timeout'.
Apr 17 03:11:46 pico-imx6ul systemd[1]: Failed to start SWUpdate daemon.

What am I missing?

Thank you,