SWUpdate Service Timeout ?
593 views
Skip to first unread message
Mickael
Apr 7, 2023, 1:03:20 AM4/7/23
to swupdate
Hello,
I am running SWUpdate on i.MX6 with Yocto/Kirkstone. I have noticed the process finishes about 30 seconds after initial boot.
What could be the reason for this timeout?
======================================
root@pico-imx6ul:/# systemctl -l status swupdate
x swupdate.service - SWUpdate daemon
Loaded: loaded (/lib/systemd/system/swupdate.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Fri 2023-04-07 04:38:31 UTC; 18min ago
TriggeredBy: * swupdate.socket
Docs: https://github.com/sbabic/swupdate
https://sbabic.github.io/swupdate
Process: 179 ExecStart=/usr/lib/swupdate/swupdate.sh (code=exited, status=0/SUCCESS)
Main PID: 179 (code=exited, status=0/SUCCESS)
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [print_registered_handlers] : preinstall
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [print_registered_handlers] : postinstall
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [network_initializer] : Main loop daemon
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [listener_create] : creating socket at /tmp/swupdateprog
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [listener_create] : creating socket at /tmp/sockinstctrl
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [start_swupdate_subprocess] : Started webserver with pid 193 and fd 10
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [start_mongoose] : Mongoose web server version 7.8 with pid 193 started on [0.0.0.0:8080] with web root [/www]
Apr 07 04:38:31 pico-imx6ul systemd[1]: swupdate.service: start operation timed out. Terminating.
Apr 07 04:38:31 pico-imx6ul systemd[1]: swupdate.service: Failed with result 'timeout'.
Apr 07 04:38:31 pico-imx6ul systemd[1]: Failed to start SWUpdate daemon.
x swupdate.service - SWUpdate daemon
Loaded: loaded (/lib/systemd/system/swupdate.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Fri 2023-04-07 04:38:31 UTC; 18min ago
TriggeredBy: * swupdate.socket
Docs: https://github.com/sbabic/swupdate
https://sbabic.github.io/swupdate
Process: 179 ExecStart=/usr/lib/swupdate/swupdate.sh (code=exited, status=0/SUCCESS)
Main PID: 179 (code=exited, status=0/SUCCESS)
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [print_registered_handlers] : preinstall
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [print_registered_handlers] : postinstall
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [network_initializer] : Main loop daemon
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [listener_create] : creating socket at /tmp/swupdateprog
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [listener_create] : creating socket at /tmp/sockinstctrl
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [TRACE] : SWUPDATE running : [start_swupdate_subprocess] : Started webserver with pid 193 and fd 10
Apr 07 04:37:01 pico-imx6ul swupdate.sh[179]: [INFO ] : SWUPDATE running : [start_mongoose] : Mongoose web server version 7.8 with pid 193 started on [0.0.0.0:8080] with web root [/www]
Apr 07 04:38:31 pico-imx6ul systemd[1]: swupdate.service: start operation timed out. Terminating.
Apr 07 04:38:31 pico-imx6ul systemd[1]: swupdate.service: Failed with result 'timeout'.
Apr 07 04:38:31 pico-imx6ul systemd[1]: Failed to start SWUpdate daemon.
Thank you,
Mickael
Mickael
Apr 8, 2023, 1:30:23 AM4/8/23
to swupdate
A little bit of an update. I have enabled systemd via the menuconfig: bitbake -c menuconfig swupdate.
Next, I am getting an error during compilation if I bitbake swupdate:
edm_yocto/build-wayland-pico-imx6ul/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/swupdate/2022.12-r0/git/core/swupdate.c:53:10: fatal error: systemd/sd-daemon.h: No such file or directory
| 53 | #include <systemd/sd-daemon.h>
| 53 | #include <systemd/sd-daemon.h>
I am expecting the layer to account for the systemd to be added to the build. What am I missing?
Thank you,
Mickael
Mickael
Apr 16, 2023, 11:44:22 PM4/16/23
to swupdate
This is solved by installing the systemd headers on the build platform.
Mickael Toumi
Jun 27, 2023, 11:53:53 PM6/27/23
to swupdate
Hello again,
(cooker log)
*
*
* SWUpdate Configuration
*
*
* SWUpdate Settings
*
*
* General Configuration
*
enable systemd support (SYSTEMD) [N/y/?] n
File with default settings (DEFAULT_CONFIG_FILE) [/etc/swupdate.cfg] /etc/swupdate.cfg
enable pre and postinstall scripts (SCRIPTS) [Y/n/?] y
check for hardware / software compatibility (HW_COMPATIBILITY) [Y/n/?] y
File with detected hardware revisions (HW_COMPATIBILITY_FILE) [/etc/hwrevision] /etc/hwrevision
File with detected software version (SW_VERSIONS_FILE) [/etc/sw-versions] /etc/sw-versions
I have use a standard bitbake -c menuconfig swupdate followed by bitbake --verbose swupdate. It feels to me something is broken.
On top of that and as mentioned previously the systemd headers need to be installed on the local host machine (sudo apt-get install libsystemd-dev as well as sudo apt-get install libsystemd). There is no special Yocto recipe for it.
There is also a need to reset the state of bitbake (bitbake -c cleansstate swupdate) to be able to get out of the
#include <systemd/sd-daemon.h> error. I think the documentation would benefit from an FAQ to highlights couple of those points.
Best regards,
Mickael
Mickael Toumi
Jun 28, 2023, 1:45:38 AM6/28/23
to swupdate
Hello,
A command like: "bitbake -c cleansstate swupdate" remove any new configs (.config.new) set by the user. So basically it reset SWUpdate to the original configuration. If I enable systemd again, I get the
#include <systemd/sd-daemon.h> error which point me back to the SWUpdate recipe. I believe I should be referencing a staging folder with the proper files, but the recipe does not do it for some reason... still looking.
Mickael Toumi
Jun 29, 2023, 10:43:03 AM6/29/23
to swupdate
Hello again,
The final word on this topic: the current released version of SWUpdate is broken in case the user set systemd as an option in menuconfig. The SWUpdate receipe does not account for systemd in DEPENDS when systemd is selected in SWudpate menuconfig (see new fix below). Without this extra step, my build is not able to find the proper header file in the staging area. The code related to "notify" written recently will demand for sd-deamon.h header that is not available. Adding this fix allow for flawless build including some of the code to do the "notify" to systemd. It is a small addition in the swupdate.inc file that should be dependent on the menuconfig selection. Now, I understand systemd is not supported by default by SWUdpate, so this modification should be dependent upon the user choice.
Thanks,
Mickael
SUMMARY="Image updater for Yocto projects"
DESCRIPTION = "Application for automatic software update from USB Pen"
SECTION="swupdate"
DEPENDS += "libconfig zlib"
# SWUpdate licensing is described in the following pages:
# https://sbabic.github.io/swupdate/licensing.html
# rst form: file://doc/source/licensing.rst
LICENSE = "GPL-2.0-or-later & LGPL-2.1-only & MIT"
LICENSE:${PN}-lua = "LGPL-2.1-only"
LICENSE:${PN}-www = "MIT"
LIC_FILES_CHKSUM = "file://LICENSES/GPL-2.0-only.txt;md5=4ee23c52855c222cba72583d301d2338 \
file://LICENSES/LGPL-2.1-or-later.txt;md5=4fbd65380cdd255951079008b364516c \
file://LICENSES/MIT.txt;md5=838c366f69b72c5df05c96dff79b35f2 \
file://LICENSES/BSD-3-Clause.txt;md5=4a1190eac56a9db675d58ebe86eaf50c"
inherit cml1 update-rc.d systemd pkgconfig
SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https;branch=master \
file://defconfig \
file://swupdate \
file://swupdate.sh \
file://swupdate.service \
file://swupdate.socket.tmpl \
file://swupdate-usb.rules \
file://swupdate-usb@.service \
file://swupdate-progress.service \
file://tmpfiles-swupdate.conf \
file://10-mongoose-args \
file://90-start-progress \
"
LTOEXTRA += "-flto-partition=none"
PACKAGES =+ " \
${PN}-client \
${PN}-lua \
${PN}-progress \
${PN}-tools \
${PN}-tools-hawkbit \
${PN}-tools-ipc \
${PN}-usb \
${PN}-www \
"
INSANE_SKIP:${PN}-lua = "dev-so"
wwwdir ?= "/www"
# tools is now an empty meta package for backward compatibility
ALLOW_EMPTY:${PN}-tools = "1"
ALLOW_EMPTY:${PN}-tools-hawkbit = "1"
ALLOW_EMPTY:${PN}-tools-ipc = "1"
FILES:${PN}-client = "${bindir}/swupdate-client"
FILES:${PN}-lua += "${libdir}/lua/"
FILES:${PN}-progress = " \
${bindir}/swupdate-progress \
${systemd_system_unitdir}/swupdate-progress.service \
${libdir}/swupdate/conf.d/90-start-progress \
"
FILES:${PN}-usb = " \
${sysconfdir}/udev/rules.d/swupdate-usb.rules \
${systemd_system_unitdir}/swupdate-usb@.service \
"
FILES:${PN}-tools-hawkbit = " \
${bindir}/swupdate-hawkbitcfg \
${bindir}/swupdate-sendtohawkbit \
"
FILES:${PN}-tools-ipc = " \
${bindir}/swupdate-ipc \
"
FILES:${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \
${systemd_system_unitdir}/swupdate.socket \
${systemd_system_unitdir}/swupdate.service \
${sysconfdir}/init.d/* \
"
FILES:${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
${wwwdir}/* \
"
RDEPENDS:${PN}-usb += "${PN}-client"
# The tools package is deprecated, it is an empty meta package for backward compatibility
RDEPENDS:${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit \
${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}-usb','',d)} \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build"
EXTRA_OEMAKE += " O=${B} HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" LIBDIR="${libdir}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
DEPENDS += "kern-tools-native systemd" <<<<<<<<<<<<<<FIX
DESCRIPTION = "Application for automatic software update from USB Pen"
SECTION="swupdate"
DEPENDS += "libconfig zlib"
# SWUpdate licensing is described in the following pages:
# https://sbabic.github.io/swupdate/licensing.html
# rst form: file://doc/source/licensing.rst
LICENSE = "GPL-2.0-or-later & LGPL-2.1-only & MIT"
LICENSE:${PN}-lua = "LGPL-2.1-only"
LICENSE:${PN}-www = "MIT"
LIC_FILES_CHKSUM = "file://LICENSES/GPL-2.0-only.txt;md5=4ee23c52855c222cba72583d301d2338 \
file://LICENSES/LGPL-2.1-or-later.txt;md5=4fbd65380cdd255951079008b364516c \
file://LICENSES/MIT.txt;md5=838c366f69b72c5df05c96dff79b35f2 \
file://LICENSES/BSD-3-Clause.txt;md5=4a1190eac56a9db675d58ebe86eaf50c"
inherit cml1 update-rc.d systemd pkgconfig
SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https;branch=master \
file://defconfig \
file://swupdate \
file://swupdate.sh \
file://swupdate.service \
file://swupdate.socket.tmpl \
file://swupdate-usb.rules \
file://swupdate-usb@.service \
file://swupdate-progress.service \
file://tmpfiles-swupdate.conf \
file://10-mongoose-args \
file://90-start-progress \
"
LTOEXTRA += "-flto-partition=none"
PACKAGES =+ " \
${PN}-client \
${PN}-lua \
${PN}-progress \
${PN}-tools \
${PN}-tools-hawkbit \
${PN}-tools-ipc \
${PN}-usb \
${PN}-www \
"
INSANE_SKIP:${PN}-lua = "dev-so"
wwwdir ?= "/www"
# tools is now an empty meta package for backward compatibility
ALLOW_EMPTY:${PN}-tools = "1"
ALLOW_EMPTY:${PN}-tools-hawkbit = "1"
ALLOW_EMPTY:${PN}-tools-ipc = "1"
FILES:${PN}-client = "${bindir}/swupdate-client"
FILES:${PN}-lua += "${libdir}/lua/"
FILES:${PN}-progress = " \
${bindir}/swupdate-progress \
${systemd_system_unitdir}/swupdate-progress.service \
${libdir}/swupdate/conf.d/90-start-progress \
"
FILES:${PN}-usb = " \
${sysconfdir}/udev/rules.d/swupdate-usb.rules \
${systemd_system_unitdir}/swupdate-usb@.service \
"
FILES:${PN}-tools-hawkbit = " \
${bindir}/swupdate-hawkbitcfg \
${bindir}/swupdate-sendtohawkbit \
"
FILES:${PN}-tools-ipc = " \
${bindir}/swupdate-ipc \
"
FILES:${PN} += " \
${libdir}/tmpfiles.d \
${libdir}/swupdate/* \
${systemd_system_unitdir}/swupdate.socket \
${systemd_system_unitdir}/swupdate.service \
${sysconfdir}/init.d/* \
"
FILES:${PN}-www = " \
${libdir}/swupdate/conf.d/*mongoose* \
${wwwdir}/* \
"
RDEPENDS:${PN}-usb += "${PN}-client"
# The tools package is deprecated, it is an empty meta package for backward compatibility
RDEPENDS:${PN}-tools += "${PN}-client ${PN}-progress ${PN}-tools-hawkbit \
${@bb.utils.contains('DISTRO_FEATURES','systemd','${PN}-usb','',d)} \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build"
EXTRA_OEMAKE += " O=${B} HOSTCC="${BUILD_CC}" HOSTCXX="${BUILD_CXX}" LD="${CC}" DESTDIR="${D}" LIBDIR="${libdir}" V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y"
DEPENDS += "kern-tools-native systemd" <<<<<<<<<<<<<<FIX
....
Stefano Babic
Jun 30, 2023, 7:56:52 AM6/30/23
to Mickael Toumi, swupdate
Hi Michael,
On 29.06.23 16:43, Mickael Toumi wrote:
> Hello again,
>
and as other packages (u-Boot, kernel). SWUpdate does not sets
statically the dependencies, but they are added by an anonymous python
function by reading the defconfig file. Because this is done before
do_config, dependencies are not updated if config is modified via
menuconfig and there is no way to do it. Adding any sort of dependencies
is silly, because a lot of packages are required to be built that are
not used in the specific project.
The way it works is:
- you run menuconfig
- you create the fragment (bitbake -c diffconfig swupdate)
- you add the fragment to your swupdate_%.bbappend
In this way, dependencies are evaluated before do_config and systemd
dependency is automatically added.
> The
> SWUpdate receipe does not account for systemd in DEPENDS when systemd is
> selected in SWudpate menuconfig (see new fix below). Without this extra
> step, my build is not able to find the proper header file in the staging
> area.
See above.
> The code related to "notify" written recently will demand for
> sd-deamon.h header that is not available. Adding this fix allow for
> flawless build including some of the code to do the "notify" to systemd.
> It is a small addition in the swupdate.inc file that should be dependent
> on the menuconfig selection. Now, I understand systemd is not supported
> by default by SWUdpate, so this modification should be dependent upon
> the user choice.
Not true, see above.
Nevertheless, just for systemd, the dependency could be added statically
by checking which virtual/init is selected (or looking into
DISTRO_FEATURES).
Best regards,
Stefano Babic
> DEPENDS += "kern-tools-native *systemd*" <<<<<<<<<<<<<<FIX
> <https://github.com/sbabic/swupdate>
> https://sbabic.github.io/swupdate
> [0.0.0.0:8080 <http://0.0.0.0:8080>] with web root
> 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/b600d68c-f605-42a7-a372-55b2328633c3n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/b600d68c-f605-42a7-a372-55b2328633c3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 29.06.23 16:43, Mickael Toumi wrote:
> Hello again,
>
> The final word on this topic: the current released version of SWUpdate
> is broken in case the user set systemd as an option in menuconfig.
The final word is it is not broken but it is not working as you expect
> is broken in case the user set systemd as an option in menuconfig.
and as other packages (u-Boot, kernel). SWUpdate does not sets
statically the dependencies, but they are added by an anonymous python
function by reading the defconfig file. Because this is done before
do_config, dependencies are not updated if config is modified via
menuconfig and there is no way to do it. Adding any sort of dependencies
is silly, because a lot of packages are required to be built that are
not used in the specific project.
The way it works is:
- you run menuconfig
- you create the fragment (bitbake -c diffconfig swupdate)
- you add the fragment to your swupdate_%.bbappend
In this way, dependencies are evaluated before do_config and systemd
dependency is automatically added.
> The
> SWUpdate receipe does not account for systemd in DEPENDS when systemd is
> selected in SWudpate menuconfig (see new fix below). Without this extra
> step, my build is not able to find the proper header file in the staging
> area.
> The code related to "notify" written recently will demand for
> sd-deamon.h header that is not available. Adding this fix allow for
> flawless build including some of the code to do the "notify" to systemd.
> It is a small addition in the swupdate.inc file that should be dependent
> on the menuconfig selection. Now, I understand systemd is not supported
> by default by SWUdpate, so this modification should be dependent upon
> the user choice.
Nevertheless, just for systemd, the dependency could be added statically
by checking which virtual/init is selected (or looking into
DISTRO_FEATURES).
Best regards,
Stefano Babic
> https://sbabic.github.io/swupdate
> [/www]
> Apr 07 04:38:31 pico-imx6ul systemd[1]:
> swupdate.service: start operation timed out.
> Terminating.
> Apr 07 04:38:31 pico-imx6ul systemd[1]:
> swupdate.service: Failed with result 'timeout'.
> Apr 07 04:38:31 pico-imx6ul systemd[1]: Failed to
> start SWUpdate daemon.
>
> Thank you,
> Mickael
>
> --
> Apr 07 04:38:31 pico-imx6ul systemd[1]:
> swupdate.service: start operation timed out.
> Terminating.
> Apr 07 04:38:31 pico-imx6ul systemd[1]:
> swupdate.service: Failed with result 'timeout'.
> Apr 07 04:38:31 pico-imx6ul systemd[1]: Failed to
> start SWUpdate daemon.
>
> Thank you,
> Mickael
>
> 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/b600d68c-f605-42a7-a372-55b2328633c3n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/b600d68c-f605-42a7-a372-55b2328633c3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Mickael Toumi
Jul 4, 2023, 11:49:14 AM7/4/23
to swupdate
Thank you Stefano for the feedback. I am accounting for the modifications you described in my current implementation. I also want to say thank you for all the hard work you and all the contributors put into this project. This is an amazing project.
Best regards,
Mickael
Reply all
Reply to author
Forward
0 new messages