# Aborting a deployment purposely stalled in the ArtifactReboot\_Enter state
**URL:** https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009
**Category:** General Discussions
**Tags:** state-scripts, mender-client
**Created:** [June 8, 2022, 4:45pm UTC](https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009 "2022-06-08T16:45:41Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@kadler](https://hub.mender.io/u/kadler)
#### Post date: [June 8, 2022, 4:45pm UTC](https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009/1 "2022-06-08T16:45:41Z")
Hi all,
I’m looking to delay rootfs updates until the user power cycles their device. My approach is based on the [Power loss](https://docs.mender.io/3.2/artifact-creation/state-scripts#power-loss) section of the state scripts documentation.
> Tip: Since a power loss in `ArtifactReboot_Enter` will not be marked as a failure, this enables the user to stall the daemon in `ArtifactReboot_Enter` state forever, and thus an install will only be installed on a power-cycle of the device.
I figured I’d create `ArtifactReboot_Enter` state script that either sleeps for days, or always returns `21` to retry later. This approach seems to work, but I noticed that if I abort the deployment from the Mender server, the Mender client continues executing the state script with either implementation.
Is there any way to get the Mender client to check on the status of, and abort, a deployment while waiting for the user to power cycle their device?
Thanks,
Kris
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [June 9, 2022, 6:01am UTC](https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009/2 "2022-06-09T06:01:38Z")
Yes, there is! You should look into the Update Control framework. You can set the device to pause either [using the server](https://docs.mender.io/overview/customize-the-update-process#synchronized-updates) or [using DBus on the client](https://docs.mender.io/client-installation/use-the-device-side-api). It can pause before the reboot indefinitely until a user reboots the device.
Your described approach with using `ArtifactReboot_Enter` won’t pause indefinitely, because the client will eventually time out the script, even if repeatedly returning 21. This is to prevent loops bricking the device. The DBus API has other ways to handle this though.
---
### Author:  [@kadler](https://hub.mender.io/u/kadler)
#### Post date: [June 13, 2022, 3:21pm UTC](https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009/3 "2022-06-13T15:21:25Z")
Thanks for the suggestion. It looks like the Update Control framework should work well for most update flows. If the user initiates reboot or shutdown, a hook can use the DBus API to tell Mender client to continue to `ArtifactReboot`. The only case I can think of where the use of a pause prior to `ArtifactReboot` will not work is if the user abruptly cuts power to the device – in that scenario, Mender client will rollback the update.
A related question – do you know when Mender client 3.3 will be released? I’d like to build pauses into deployments via Mender server, but I’m seeing failures related to issue [MEN-5421](https://tracker.mender.io/browse/MEN-5421) in versions 3.0 and 3.1, and unrelated failures in version 3.2, which may be related to problems described in this Mender Hub thread:
> [@Mender keeps rolloing back after update](https://hub.mender.io/t/mender-keeps-rolloing-back-after-update/4705/15):
>
> Im having the same Problem. Downgrading to version 3.1.0 solves the issue. This forces me to use mender-connect 1.2 which has a bug losing connection to the server quite often.
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [June 14, 2022, 7:04am UTC](https://hub.mender.io/t/aborting-a-deployment-purposely-stalled-in-the-artifactreboot-enter-state/5009/4 "2022-06-14T07:04:32Z")
> [@kadler](#):
>
> Thanks for the suggestion. It looks like the Update Control framework should work well for most update flows. If the user initiates reboot or shutdown, a hook can use the DBus API to tell Mender client to continue to `ArtifactReboot`. The only case I can think of where the use of a pause prior to `ArtifactReboot` will not work is if the user abruptly cuts power to the device – in that scenario, Mender client will rollback the update.
That’s correct. You can use the Retry function on the server to mitigate that though. The device will have to re-download the artifact, but it will at least be automatic.
> [@kadler](#):
>
> A related question – do you know when Mender client 3.3 will be released? I’d like to build pauses into deployments via Mender server, but I’m seeing failures related to issue [MEN-5421](https://tracker.mender.io/browse/MEN-5421) in versions 3.0 and 3.1, and unrelated failures in version 3.2, which may be related to problems described in this Mender Hub thread:
3.3.0 was tagged today, as a matter of fact! There is still some work to make sure that Yocto, website, etc. is up to date, but it’s just a matter of a short time now.