Add ability to cancel an update?

[RyuzakiKK]

The RAUC service API currently gives you the ability to start an update with the "Install" method, but then, once started, there is no turning back.

A user however might want to cancel an update for a variety of reasons, e.g. it doesn't have time at the moment.

Of course cancelling a midway installed update will likely result in an unusable partition, but that might be okay depending on the system partitions layout.

Currently cancelling an update can be achieved by sending a SIGTERM to the RAUC service, but that kills the entirely RAUC service.
Would you be interested in making this an officially supported option by adding a "Cancel", or "Abort", method in the D-Bus API?
I'd like your opinion on this matter before I start to actually implement it.

[ejoerns]

Indeed, cancellation is not possible at the moment.

Could you give some more background why this is needed for your use case?
When you install an update and want to cancel it, you could potentially wait for the installation procedure to be completed and then mark the slot as 'bad' afterward so that it will not be selected on a reboot.

[RyuzakiKK]

Applying an update is potentially a long operation.

If for example the device is battery powered, halfway through an update the user might decide that he doesn't want to apply the update anymore to save battery and that he'd prefer to cancel the operation and try it again once he'll be able to plug the device to the AC.

Another use case is for example when the user doesn't have time to wait for an update to complete, e.g. he is in a hurry, he wants to shut down the device etc..., so he'd like to have the ability to cancel an update that is currently in progress.

[jluebbe]

So far, we've avoided to additional complexity of being able to support cancelling an installation. We'd need to be able to abort external processes (tar, casync, flashcp/-erase, mkfs.*, ...) and internal copy functions. In both cases, it would need to be passed through a few function calls. Also, we'd need a way to test cancellations properly.

I'm skeptical if this can be achieved with a good balance of complexity and maintenance cost relative to the benefit of cancelling. I'd be willing to be convince otherwise with a prototype, though.

On the other hand, killing the RAUC systemd service probably achieves 90% of the result without additional code. By keeping more state of the ongoing transaction on disk we might be able make this easier to use.

[jluebbe]

Conceptually, this could also be related to the ability to 'pause' installations. I'm perhaps something could be done using the cgroup freezer and moving the actual installation to a child of the rauc process (but that would require reworking the progress handling).

[jluebbe]

Thinking about this a bit more, it might also be possible to use device-mapper to implement this feature. With verity bundles, we use a dm-verity dm device, which we could force-remove, suspend or resume. The force remove would then allow us to use the existing error handling paths.

[RyuzakiKK]

Okay, once I have some spare time I'll try to sketch a first proof of concept implementation (unless someone else does it first).

[RyuzakiKK]

Just a quick update here, this is still a function that we'd like to have. For now we are pausing and cancelling updates with SIGSTOP and SIGTERM. And while this works fine, it will be good to have proper support in RAUC.

I don't have an ETA on when I'll be able to work on this task, but it is still in my TODO list.

[jluebbe]

Just a quick update here, this is still a function that we'd like to have. For now we are pausing and cancelling updates with SIGSTOP and SIGTERM. And while this works fine, it will be good to have proper support in RAUC.

Agreed. I still think that the approach described in #841 (comment) would be the easiest way to support this, as we can reuse the existing error handing code paths.

I don't have an ETA on when I'll be able to work on this task, but it is still in my TODO list.

Thanks! When it comes to the top of your list, please don't hesitate to talk to us about implementation details or show us a prototype implementation.

[RyuzakiKK]

@jluebbe would it be Okay to start using a device mapper, e.g. a linear one I suppose, for plain bundles as well? Or would you prefer to keep the pause/stop functionality only for verity and crypt while leaving plain out?