Re: [pbs-devel] [PATCH backup] fix #3336: cleanup when deleting last snapshot

["Shannon Sterz" <s.sterz@proxmox.com>]

On Tue Mar 11, 2025 at 10:21 AM CET, Thomas Lamprecht wrote:
> On 10/03/2025 16:22, Shannon Sterz wrote:
>> On Mon Mar 10, 2025 at 4:19 PM CET, Fabian Grünbichler wrote:
>>>> Wolfgang Bumiller <w.bumiller@proxmox.com> hat am 10.03.2025 11:53 CET geschrieben:
>>>> On Fri, Mar 07, 2025 at 04:53:14PM +0100, Shannon Sterz wrote:
>>>>> On Fri Mar 7, 2025 at 4:33 PM CET, Wolfgang Bumiller wrote:
>>>>>> On Fri, Mar 07, 2025 at 11:37:32AM +0100, Shannon Sterz wrote:
>>>>>> IIRC we need to figure out a good upgrade strategy so running processes
>>>>>> don't use different locking.
>>>>>>
>>>>>> One idea was to have the postinst script create a file in run (eg
>>>>>> `/run/proxmox-backup/old-locking`) which, when present, instructs the
>>>>>> daemons to keep using the old strategy.
>>>>>>
>>>>>> The new one would then automatically be used after either a reboot, or
>>>>>> manually removing the file between stop & start of the daemons.
>>>>>
>>>>> yeah i remember that being a blocker, but since pbs 4 is coming up
>>>>> soon-ish, couldn't we just apply it then? upgrading between 3 -> 4
>>>>> requiring a reboot seems reasonable to me, though maybe i'm missing
>>>>> something (e.g. could it be problematic to have the services running,
>>>>> even shortly, before the reboot?).
>>>>>
>>>>> if that would be an option, it'd be much simpler than carrying around
>>>>> that switching logic forever (or at least one major version?). also,
>
> One major version would be enough for all practical cases as we require
> a reboot for the new kernel after an upgrade, which ensures that no old
> PBS processes are around anymore as side effect. So people staying on EOL
> version for a while and then do two major upgrades in quick succession
> without any reboot are a bit on their own anyway, adding a hint to the
> upgrade docs for that case would be cheap though and cover those admins
> that actually try to do a good job and are just fixing such an outdated
> setup without having been the one that caused it to exist in the first
> place.
>
>>> I don't think that works, unless we want to require putting all datastores
>>> into maintenance mode prior to the upgrade and until the system has been
>>> rebooted?
>>>
>>> otherwise, the upgrade from 3.x to 4.x is just like any other, with all the
>>> same problems if the old proxy still has a backup or other lock-holding task
>>> running and the new one uses different locking..
>
> That's what the flag is for, touch it on upgrade before the new daemon
> starts, in the new daemon set an internal global OnceLock (or the like)
> guarded flag and use that to determine if old or new locking needs to be
> used. On the next reboot the flag won't be there anymore and thus new
> locking mode is used.

hm since this was sparked by the group removal bug (the one that leaves
the owner file in place), that would mean we can only fix that once we
are sure that the new locking mechanism is used? or do we build in that
contingency there too?

can send a v7 that adds the locking strategy switch later today
probably.

>> i feel like it would be fine to do that though? we already optionally
>> recommended that when upgrading from 2 -> 3 [1]. so requiring that and
>> documenting it in the upgrade notes sounds fine to me.
>>
>> [1]: https://pbs.proxmox.com/wiki/index.php/Upgrade_from_2_to_3#Optional:_Enable_Maintenance_Mode
>
> can be an option, but not requiring user doing this is always nicer for
> them and our support.



_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel