Open acasadoual opened 6 years ago
Hi @acasadoual,
Change on a *_task
parameter looks taking effect after the next execution of corresponding task.
For example: If remind_task
has been set to monthly
and it was changed to yearly
, remind
task will be executed in a month and then executed one more year after.
On the problem pointed out in Additional information looks bug and I'll investigate it.
Hi @ikedas , Yes, the worst situation is when the task is first set up annually and then changed monthly. If we have configured the task and then deactivate it, the task is not deleted.
Hi @acasadoual,
I agree it is uncomfortable for owners that setting will not be available soon.
However, I feel current behavior is reasonable in a sence:
If the next time of execution could be changed after the last execution, when the duration (monthly, yearly etc.) will be based on? For example, when the next execution should occur in the following cases?
yearly
, and task executed. 27 days after execution, we set monthly
.yearly
, and task executed. 2 months after execution, we set monthly
.yearly
, and task executed. 63 days after execution, we set bi-monthly
, and immediately set monthly
.@ikedas said: The next time of execution will be decided according to the setting at the time of the last execution.
But the next time of execution is in the task file, no in the setting. Example, I set it yearly first, and later i set to monthly, the task file no changed of its creation:
$ more 1573121056.EXEC.remind.prueba-stic@lista.ual.es
title.gettext reminder message sent to subscribers every year
/INIT
next(execution_date+1y,EXEC)
/EXEC
@selection = select_subs (older(execution_date))
send_msg (@selection, remind)
next(execution_date+1y,EXEC)
You say the same as I said. In your example:
@acasadoual, what I want to ask you is when do you think the change of setting should be reflected.
If I change a parameter, that change must be immediate (it is in the configuration and not in the task) and not wait for the next execution. Example, if I change a reminder parameter from annually to monthly, it should be done: a) delete all pending tasks: rm /var/spool/sympa/task/*.remind.foolist@bar b) create a remind task INIT: now.INIT.remind.foolist@bar
Responses: We set yearly, and task executed. 27 days after execution, we set monthly. The next month. We set yearly, and task executed. 2 months after execution, we set monthly. The next month. We set yearly, and task executed. 63 days after execution, we set bi-monthly, and immediately set monthly. The next month.
... because I have a button in the GUI "Remind all" to run it now if I want.
It is not assumable that if the parameter is yearly and has just been executed recently, i set to monthly it will take 2 years for it to be configured monthly (1 year to execute the task file, 1 year to change the task file).
Regards
I understand you mean that the next execution occur at one month after the last change of setting (not one month after the last execution in the first case, nor immediately in the second and third cases).
Version
6.2.37B2
Installation method
rpm of sympa-ja.org
Expected behavior
When i modify remind_task parameter via GUI, the configuration file and previous task (if it exists) should change.
Actual behavior
The configuration file change, but the previous task no change.
Additional information
If no set the parameter, the parameter in config file is set to nothing: ... remind_task ... and i see one error in sympa.log:
Nov 7 14:08:19 alboran sympa_msg[30041]: info Sympa::List::_load_list_config_file() Bad entry "remind_task " in /var/lib/sympa/list_data/prueba-stic/config Nov 7 14:08:19 alboran task_manager[30043]: info Sympa::List::_load_list_config_file() Bad entry "remind_task " in /var/lib/sympa/list_data/prueba-stic/config