After upgrading from 2.4.120 to 2.4.130, after a reboot, manager is unable to start its containers
#14408
-
Version2.4.130 Installation MethodSecurity Onion ISO image Descriptionother (please provide detail below) Installation TypeDistributed Locationon-prem with Internet access Hardware SpecsExceeds minimum requirements CPU32 RAM384 GiB Storage for /145 GB (manager) Storage for /nsm291 GB (manager) Network Traffic Collectiontap Network Traffic Speeds1Gbps to 10Gbps StatusNo, one or more services are failed (please provide detail below) Salt StatusYes, there are salt failures (please provide detail below) LogsYes, there are additional clues in /opt/so/log/ (please provide detail below) DetailAfter upgrading from 2.4.120 to 2.4.130, some five days ago, I first had issues with Kibana. In my case this was solved by manually restarting the Kibana container on the manager. Today, I wanted to adjust the Stenographer settings, but I couldn't access the configuration tree. I decided to restart the manager. Now, the manager is desperately trying to start the containers, but falling short. This snippet is from Guidelines
|
Beta Was this translation helpful? Give feedback.
Answered by
Ximalas
Mar 19, 2025
Replies: 5 comments 3 replies
-
|
I have lately been deactivating multiple alerts and tuning other alerts to be ignored for certain source IP addresses. There might be a connection. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Looking at And the last few lines read: I deleted the last, incomplete line and saved the file. This allowed Salt to recover. The sister file If possible, it would help if full pathnames to configuration files to be read are announced when containers/services are about to be started. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Hello @Ximalas ! I'm glad you were able to resolve your own issue. Just out of curiosity, is it possible that you were manually editing If that's the case, we recommend that you do not manually edit these files using text editors. We've built web interfaces so that you don't have to manually edit these files and that should help avoid improper syntax like this. https://docs.securityonion.net/en/2.4/detections.html |
Beta Was this translation helpful? Give feedback.
-
|
No, that's not the case. I'm at the mercy of the web interface and its speed and latency. Funny enough, alerts I disabled while running 2.4.100 or so, have started to appear in the alert list. When I click on the information icon, sure enough, the alert is really disabled. |
Beta Was this translation helpful? Give feedback.
-
We can't come up with any reason why the web interface would write out that partial flowbits line like that. Are you sure that nobody else has access to your system who may have manually edited the file?
Not sure what you mean by this. SOC is fast and low latency for our installations.
If you need help troubleshooting this, please start a new discussion with appropriate title and provide further information. |
Beta Was this translation helpful? Give feedback.
Answer selected by
Ximalas
-
|
It's difficult to relate this error message to a particular container/service. Some additional error messages popped up in this log file: An inspection revealed: Rerunning The failure is: The file |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
So far, all is good within the manager, according to |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
My initial problem, accessing the configuration tree, has been solved. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Looking at
/opt/so/saltstack/local/pillar/idstools/soc_idstools.sls, the first few lines read:And the last few lines read:
I deleted the last, incomplete line and saved the file. This allowed Salt to recover.
The sister file
/opt/so/saltstack/local/pillar/idstools/adv_idstools.slsis empty.If possible, …