[pmg-devel] [PATCH api v4 02/10] pmg-smtp-filter: move pid file into /run/pmg-smtp-filter

[Fiona Ebner]

CC-ing pmg-devel again

Am 15.07.24 um 14:02 schrieb Maximiliano Sandoval:
> Fiona Ebner <f.ebner at proxmox.com> writes:
> 
>> Am 10.07.24 um 16:35 schrieb Maximiliano Sandoval:
>>> diff --git a/src/PMG/Utils.pm b/src/PMG/Utils.pm
>>> index 5d9ded4..09cb42d 100644
>>> --- a/src/PMG/Utils.pm
>>> +++ b/src/PMG/Utils.pm
>>> @@ -1462,7 +1462,7 @@ sub get_pg_server_version {
>>>  
>>>  sub reload_smtp_filter {
>>>  
>>> -    my $pid_file = '/run/pmg-smtp-filter.pid';
>>> +    my $pid_file = '/run/pmg-smtp-filter/pmg-smtp-filter.pid';
>>>      my $pid = PVE::Tools::file_read_firstline($pid_file);
>>>  
>>>      return 0 if !$pid;
>>
>> Can there be a race here during/after update? I.e. service still running
>> with PID file in old path and reload_smtp_filter() is called only
>> checking the new path. Does something ensure this can't happen?
>> Otherwise, I suppose we'll need to check the old path too until the next
>> major release.
>>
>> And what about the other way around, i.e. service already running with
>> PID file in new path and old version of reload_smtp_filter() called
>> still checking the old path?
> 
> I am not entirely sure to be honest. Every service will be restarted
> after the install so at most there could be races during the install
> process.
> 

But the src/PMG/Utils.pm file is used by other services too, right?  And
it seems likely that reload_smtp_filter() can be reached by those, e.g.
one caller is PMG/Config.pm's rewrite_config().

> I am not sure how this is handled in perl, but my understanding is that
> the file is in memory until the service is restarted in which case I
> don't think there should be any race in this window either.
>