[PATCH] systemd.bbclass: don't block on service restart

[PATCH] systemd.bbclass: don't block on service restart

[Mark Asselstine]

The current class works fine when a recipe uses SYSTEMD_AUTO_ENABLE
'enable' and has no on device pkg_postinst(), ie when the postinst is
run as part of rootfs creation.  However, when there is a component of
pkg_postinst() that is run on device the 'systemctl restart' is run as
part of the run_postinsts.service at boot. This results in the boot
spinning indefinitely with:

[ *** ] A start job is running for Run pending postinsts (7s / no limit)

The issue could potentially be that the packages service has an
'After' clause which comes later in the boot, beyond
run_postinsts.service, creating a chicken before the egg
scenario. Even service files without an 'After' clause cause this
situation however. Despite this not being the cause of the issue this
fix will prevent this scenario from happenning.

Using strace we are able to find that during boot, when
run_postinsts.service is running attempting to start or restart any
service will result in the call get stuck on poll(). Since the
run_postinsts.service does not monitor the outcome of the call to
restart we can work around this by using '--no-block'.

Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
---
 meta/classes/systemd.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 7e51ed6..99a08a0 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -36,7 +36,7 @@ if type systemctl >/dev/null 2>/dev/null; then
 	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
 
 	if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
-		systemctl restart ${SYSTEMD_SERVICE}
+		systemctl --no-block restart ${SYSTEMD_SERVICE}
 	fi
 fi
 }
-- 
2.7.4

Re: [PATCH] systemd.bbclass: don't block on service restart

[Andreas Oberritter]

On 25.11.2016 05:17, Mark Asselstine wrote:
> The current class works fine when a recipe uses SYSTEMD_AUTO_ENABLE
> 'enable' and has no on device pkg_postinst(), ie when the postinst is
> run as part of rootfs creation.  However, when there is a component of
> pkg_postinst() that is run on device the 'systemctl restart' is run as
> part of the run_postinsts.service at boot. This results in the boot
> spinning indefinitely with:
> 
> [ *** ] A start job is running for Run pending postinsts (7s / no limit)
> 
> The issue could potentially be that the packages service has an
> 'After' clause which comes later in the boot, beyond
> run_postinsts.service, creating a chicken before the egg
> scenario. Even service files without an 'After' clause cause this
> situation however. Despite this not being the cause of the issue this
> fix will prevent this scenario from happenning.
> 
> Using strace we are able to find that during boot, when
> run_postinsts.service is running attempting to start or restart any
> service will result in the call get stuck on poll(). Since the
> run_postinsts.service does not monitor the outcome of the call to
> restart we can work around this by using '--no-block'.
> 
> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>

I was going to submit the exact same patch soon. It also helps to
complete system updates if a service fails to restart properly.

Acked-by: Andreas Oberritter <obi@opendreambox.org>

> ---
>  meta/classes/systemd.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> index 7e51ed6..99a08a0 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -36,7 +36,7 @@ if type systemctl >/dev/null 2>/dev/null; then
>  	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
>  
>  	if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> -		systemctl restart ${SYSTEMD_SERVICE}
> +		systemctl --no-block restart ${SYSTEMD_SERVICE}
>  	fi
>  fi
>  }
> 

Re: [PATCH] systemd.bbclass: don't block on service restart

[Khem Raj]

> On Nov 24, 2016, at 8:17 PM, Mark Asselstine <mark.asselstine@windriver.com> wrote:
> 
> The current class works fine when a recipe uses SYSTEMD_AUTO_ENABLE
> 'enable' and has no on device pkg_postinst(), ie when the postinst is
> run as part of rootfs creation.  However, when there is a component of
> pkg_postinst() that is run on device the 'systemctl restart' is run as
> part of the run_postinsts.service at boot. This results in the boot
> spinning indefinitely with:
> 
> [ *** ] A start job is running for Run pending postinsts (7s / no limit)

yeah usually it would be nice if there was some sort of timeout on failed
restarts

> 
> The issue could potentially be that the packages service has an
> 'After' clause which comes later in the boot, beyond
> run_postinsts.service, creating a chicken before the egg
> scenario. Even service files without an 'After' clause cause this
> situation however. Despite this not being the cause of the issue this
> fix will prevent this scenario from happenning.
> 
> Using strace we are able to find that during boot, when
> run_postinsts.service is running attempting to start or restart any
> service will result in the call get stuck on poll(). Since the
> run_postinsts.service does not monitor the outcome of the call to
> restart we can work around this by using '--no-block'.
> 
> Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
> ---
> meta/classes/systemd.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> index 7e51ed6..99a08a0 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -36,7 +36,7 @@ if type systemctl >/dev/null 2>/dev/null; then
> 	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
> 
> 	if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> -		systemctl restart ${SYSTEMD_SERVICE}
> +		systemctl --no-block restart ${SYSTEMD_SERVICE}
> 	fi
> fi
> }
> -- 
> 2.7.4
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core