What installation are you running?
Production (netalertx) 📦
Is there an existing issue for this?
The issue occurs in the following browsers. Select at least 2.
Current Behavior
Regarding this, I was wondering if I could make nodes start scanning like 2 minutes before the scan on the hub. Given that I have cron on hub set as */20 * * * *, I was thinking about setting cron as 18,38,58 * * * * on the nodes, so that they could start scanning with a 2-minute margin before the hub and, when hub asks them for their devices list, it is basically guaranteed to receive all up-to-date lists (removing the race condition that seems to be also happening in PULL mode if the devices list is not yet updated on node - this was not an issue with the old implementation because the node itself was triggering New Device events, so they were sent as soon as the node discovered them, even if they weren't synced yet on hub on that specific iteration, while now if hub asks for devices lists too early, it could miss new devices that are still in progress to be added on the node, and start sending alerts on its next iteration):
..
I've also tested something like 18-59/20 * * * * that should achieve the same result, and it is also not accepted.
reported by @Rikysonic
Expected Behavior
Valid Cron entries accepted
Steps To Reproduce
No response
Relevant app.conf settings
docker-compose.yml
Debug or Trace enabled
Relevant app.log section
PASTE LOG HERE. Using the triple backticks preserves format.
Docker Logs
PASTE DOCKER LOG HERE. Using the triple backticks preserves format.
What installation are you running?
Production (netalertx) 📦
Is there an existing issue for this?
The issue occurs in the following browsers. Select at least 2.
Current Behavior
Regarding this, I was wondering if I could make nodes start scanning like 2 minutes before the scan on the hub. Given that I have cron on hub set as */20 * * * *, I was thinking about setting cron as 18,38,58 * * * * on the nodes, so that they could start scanning with a 2-minute margin before the hub and, when hub asks them for their devices list, it is basically guaranteed to receive all up-to-date lists (removing the race condition that seems to be also happening in PULL mode if the devices list is not yet updated on node - this was not an issue with the old implementation because the node itself was triggering New Device events, so they were sent as soon as the node discovered them, even if they weren't synced yet on hub on that specific iteration, while now if hub asks for devices lists too early, it could miss new devices that are still in progress to be added on the node, and start sending alerts on its next iteration):
..
I've also tested something like 18-59/20 * * * * that should achieve the same result, and it is also not accepted.
reported by @Rikysonic
Expected Behavior
Valid Cron entries accepted
Steps To Reproduce
No response
Relevant
app.confsettingsdocker-compose.yml
Debug or Trace enabled
Relevant
app.logsectionDocker Logs