Closed jnweiger closed 6 days ago
For the non-systemd case, I'd suggest to consider killall -v -s 15 ocis
(or a regexp variation of this)
ok. this sounds valid. I will create a new PR independent to the migration so we can backport to cover:
Thanks for the investigation in filing the issue 👍
The upgrade guide correctly suggests to stop ocis before updating. The binary / bare metal install case is discussed in https://github.com/owncloud/docs-ocis/blob/2360692c5141e4fb8145a80fe46f52b6a7a87c4a/modules/ROOT/pages/migration/upgrading_5.0.x_7.0.0.adoc#2-shut-down-the-infinite-scale-instance
which correctly refers the user to: https://github.com/owncloud/docs-ocis/blob/master/modules/ROOT/pages/depl-examples/minimal-bare-metal.adoc#stopping-infinite-scale
There we learn, that for a graceful and complete shutdown, a rather complex shell pipeline should be used:
But: When the bare metal install was done according to https://doc.owncloud.com/ocis/next/depl-examples/bare-metal.html#setup-the-systemd-service this will not have the desired effect.
Systemd treats the kill -15 command as an incorrect shutdown and restarts ocis immediately. This behavior is correctly configured in the service file via
Restart=always
- This is a valuable safeguard against spurious crashes.Thus following this procedure, we'll have ocis unintentionally running while doing the remaining upgrade steps. This most likely leads to errors, frustrated users or even data-loss.
I suggest, that for each setup, the respective tooling is used and we properly distinguish the systemd case from other binary deployments. For a systemd setup, the correct command for a graceful and complete shutdown is:
service ocis stop