auto-update: allow to use custom command when stopping container

[gdesmott]

/kind feature

Description

I manually implemented a script very similar to podman-auto-update. The only thing blocking me from switching to it is the ability to use a custom command to stop the running container.
I send a request to my server telling it to set itself in "maintenance" mode so it will stop accepting new requests from clients and automatically shutdown itself when all the clients have been disconnected. This ensure seamless upgrades as clients are not disconnected right away when upgrading.

Would it be possible to have something like this with auto-update? Something a bit similar to watchtower's hooks may do.

[vrothberg]

Thanks for reaching out, @gdesmott!

What you could do is to change the generated systemd unit:

Before

ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id

After

ExecStop= *** CUSTOM SHUTDOWN LOGIX ***
ExecStopPost=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id

Note that customizing the generated units will leave supported territory. Any chance your workload can handle SIGTERM? That's what podman stop sends to the container initially.

[gdesmott]

Thanks for your quick reply @vrothberg :)

Note that customizing the generated units will leave supported territory.

Yes, I'd rather keep my own update script than doing such error-prone hacks.

Any chance your workload can handle SIGTERM? That's what podman stop sends to the container initially.

I considered that, but my container has a entrypoint.sh script starting the binary server and I didn't find a way to easily forward signals to the actual binary.

[vrothberg]

@gdesmott, can you elaborate on the problems you faced trying to forward the signal? Did you run the container with --init?

That is the only idea (for a supported solution) I have at the moment.

[gdesmott]

Did you run the container with --init?

I did not. Will that automatically signal from entrypoint.sh to the server binary it started?

[vrothberg]

I did not. Will that automatically signal from entrypoint.sh to the server binary it started?

I can't tell for sure but it's worth testing. The --init binary will only forward to spawned process but some shells exec on the last command instead of forking (see #13324 (comment)), so it may "just work".

[Luap99]

I don't think that adding hooks to podman auto-update is more useful then just running the commands before/afterwards.

You can also just put this into a script:

custom command
podman auto-update
custom command

[vrothberg]

@Luap99, I don't that fits the use case. The "custom stop command" should only be executed during auto-update. If there's nothing to update, nothing should happen.

[Luap99]

Ah, that's true.

[vrothberg]

I did not. Will that automatically signal from entrypoint.sh to the server binary it started?

I can't tell for sure but it's worth testing. The --init binary will only forward to spawned process but some shells exec on the last command instead of forking (see #13324 (comment)), so it may "just work".

@gdesmott did it work using --init?

[gdesmott]

I didn't have a chance to test it yet. It's definitely on my TODO list but it makes take a while, so feel free to close this ticket for now if you think adding such feature does not make sense.

[vrothberg]

Sounds good to me. Please let us know how it worked out.