Description
We just upgraded one of our instances from 5.6.2 --> 5.7.6 - it looks like the AlienVault connector had a "job" in progress when the platform was shutdown, and the job has not resumed or completed now that the upgrade is complete. Subsequently scheduled jobs by that same connector seem to work okay. It's not clear if any data/work was lost - whether the job actually completed and just wasn't marked as complete, or whether the job actually was lost.
Environment
- OS (where OpenCTI server runs): { e.g. Mac OS 10, Windows 10, Ubuntu 16.4, etc. } Docker 24.0.1 and Docker Compose version v2.18.1 on Ubuntu 22 (we use the provided Docker Compose configuration)
- OpenCTI version: { e.g. OpenCTI 1.0.2 } 5.7.6
- OpenCTI client: { e.g. frontend or python } N/A
Reproducible Steps
Steps to create the smallest reproducible scenario:
1.Have a Docker Compose version of the platform on version 5.6.2
2. Wait until an AlienVault job is in progress (I think the logs will say something like "Pulse importer completed (imported: {0}")
3. Check that the workers are processing the new work - they will show events in the Docker logs, or presumably in your Elastic logs
4. Stop OpenCTI gracefully (in my case, docker compose down)
5. Upgrade the docker compose configuration to 5.7.6
6. Start the system up again (docker compose up -d)
7. Observe that the page for the connector (e.g. AlienVault) will show a job in progress, with a start time before the upgrade, which will not finish/complete
Expected Output
I would expect the work in progress to be paused or cached somewhere when the system is shutdown, and that it should be resumed when the system comes back up.
Actual Output
A connector job is created "in progress", but not finished. See the following screenshot, which shows the stuck 10:35 job, and a subsequent 11:52 job which completed without issue:
Additional information
Note: our system is in UK TZ, which I believe explains why some timestamps show up an hour ahead of some others.
Unfortunately, the Docker log seems to have been wiped after the upgrade, so I do not think it covers the events in question. This could be how docker compose works, or could be a side-effect of how we use it.
Description
We just upgraded one of our instances from 5.6.2 --> 5.7.6 - it looks like the AlienVault connector had a "job" in progress when the platform was shutdown, and the job has not resumed or completed now that the upgrade is complete. Subsequently scheduled jobs by that same connector seem to work okay. It's not clear if any data/work was lost - whether the job actually completed and just wasn't marked as complete, or whether the job actually was lost.
Environment
Reproducible Steps
Steps to create the smallest reproducible scenario:
1.Have a Docker Compose version of the platform on version 5.6.2
2. Wait until an AlienVault job is in progress (I think the logs will say something like "Pulse importer completed (imported: {0}")
3. Check that the workers are processing the new work - they will show events in the Docker logs, or presumably in your Elastic logs
4. Stop OpenCTI gracefully (in my case,
docker compose down)5. Upgrade the docker compose configuration to 5.7.6
6. Start the system up again (
docker compose up -d)7. Observe that the page for the connector (e.g. AlienVault) will show a job in progress, with a start time before the upgrade, which will not finish/complete
Expected Output
I would expect the work in progress to be paused or cached somewhere when the system is shutdown, and that it should be resumed when the system comes back up.
Actual Output
A connector job is created "in progress", but not finished. See the following screenshot, which shows the stuck 10:35 job, and a subsequent 11:52 job which completed without issue:
Additional information
Note: our system is in UK TZ, which I believe explains why some timestamps show up an hour ahead of some others.
Unfortunately, the Docker log seems to have been wiped after the upgrade, so I do not think it covers the events in question. This could be how docker compose works, or could be a side-effect of how we use it.