podman-remote-pull - service pulls even when client is killed

[vrothberg]

/kind bug

Description

When killing a podman-remote pull $IMAGE the service continues pulling.

Steps to reproduce the issue:

1. podman system service -t0

2. podman-remote pull alpine + CTRL+C

Describe the results you received:

Service pulls the image.

Describe the results you expected:

Service should cancel the pull/copy operation

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Podman v2.0.X and following.

[mheon]

For reference, I think Docker works like this as well - so it's not the worst thing if we do as well...

[mheon]

Still, we need a big rework of the Pull endpoint anyways (it needs to stream progress back to the client). We can probably accommodate this as part of that.

[rhatdan]

Is this really a bug? Or is this expected behaviour. If I pulled a huge image and the network went down, I would be happy that the image completed.

[vrothberg]

Docker does not continue pulling.

If I pulled a huge image and the network went down, I would be happy that the image completed.

The speed of our link at home is quite poor (a couple 100 meters far from fibre unfortunately). If I accidentally pull a huge image and CTRL^C the client I want it to stop pulling. If it continued, I had to kill the service.

[vrothberg]

Labelling it as a feature for now. Remote pull is working and other items have a higher priority.

To make it work, we first have to allow copy.Image(...) in c/image to be cancellable via the provided context.Context.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@mtrmac PTAL

[mtrmac]

To make it work, we first have to allow copy.Image(...) in c/image to be cancellable via the provided context.Context.

Isn’t it cancellable already? At the very least

• the Docker transport’s makeRequestToResolvedURL is cancellable
• copySemaphore.Acquire is cancellable
  and that should propagate up.

That might well not be good enough (maybe if we manage to kick off copyLayerHelper for all layers, I don’t immediately know how much work each of them does before noticing a pending cancellation, and there are quite a few “// TODO: This can take quite some time, and should ideally be cancellable using ctx.Done().” pending comments added at the time contexts were added), but I did think we got the basics done at least.

[mtrmac]

OTOH https://github.com/containers/image/blob/master/internal/uploadreader/upload_reader.go — that was ugly. It’s quite possible that the HTTP stack is similarly continuing to receive data (for a limited time, I hope) regardless of cancellation. (I haven’t checked in detail at this point.)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg I take it that this has not been fixed and is still an issue?

[vrothberg]

Yes. I don't think anybody found time to tackle it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg Should we be raising the priority on this one now?

[vrothberg]

@vrothberg Should we be raising the priority on this one now?

It depends on the free cycles. My queue is long but I can certainly give guidance fixing it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Sadly another month has passed.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@vrothberg Any chance you can look at this?
@Luap99 @cdoern Interested?

[Luap99]

I take a look.

[vrothberg]

Thanks, @Luap99. I haven't tested it in a long while. It may have already been fixed in the meanwhile.