Docker-based Engine Keeps Disconnecting
Hey guys,
I have a working crowdsec/traefik config running via Docker Compose. My issue is that it seems that I get the engine registered in the container via cscli enroll and it will work for a few hours then just stop checking in.
What's the best way to register the container's engine and make 100% sure it won't just disappear?
24 Replies
Important Information
Thank you for getting in touch with your support request. To expedite a swift resolution, could you kindly provide the following information? Rest assured, we will respond promptly, and we greatly appreciate your patience. While you wait, please check the links below to see if this issue has been previously addressed. If you have managed to resolve it, please use run the command
/resolve or press the green resolve button below.Log Files
If you possess any log files that you believe could be beneficial, please include them at this time. By default, CrowdSec logs to /var/log/, where you will discover a corresponding log file for each component.
Guide Followed (CrowdSec Official)
If you have diligently followed one of our guides and hit a roadblock, please share the guide with us. This will help us assess if any adjustments are necessary to assist you further.
Screenshots
Please forward any screenshots depicting errors you encounter. Your visuals will provide us with a clear view of the issues you are facing.
© Created By WhyAydan for CrowdSec ❤️
Can anyone help me with this? I always lose my engine registration when I reboot the host
Do you have a persistent volume ?
Yes, I do
apologies for the delayed response
Here's my compose. I'm using Crowdsec in conjunction with Traefik
was the crowdsec container running when you saw those errors ?
It means crowdsec took too long to response to the query: a simple refresh of the decision should take tens of milliseconds in theory, so highly unlikely for the request to timeout.
Could you also provide the logs from the crowdsec container when it starts ? You configuration seems ok (you persist both the configuration and the db), so the console should remember your instance.
Can you also confirm that between 2 restarts of the crowdsec container, the content of
/etc/crowdsec/online_api_credentials.yaml stays the same ?Yes, the container was running with that log. I deleted the engine and recreated, fixed an issue in my compose with conflicting volume mounts, re-enrolled it in the console and now i'm getting the error on the right
after a reboot, i'm no longer enrolled
root@interact-traefik:/etc/docker/crowdsec# docker compose up 2>&1 | grep --line-buffered -E 'level=(error|warning)'
time="2025-09-29T17:50:41Z" level=warning msg="The "remote_ip" variable is not set. Defaulting to a blank string."
time="2025-09-29T17:50:41Z" level=warning msg="The "remote_ip" variable is not set. Defaulting to a blank string."
crowdsec-engine | time="2025-09-29T12:50:45-05:00" level=error msg="Machine is not enrolled in the console, can't synchronize with the console"
crowdsec-engine | time="2025-09-29T12:50:45-05:00" level=warning msg="scenario list is empty, will not pull yet"
what type of disk do you have on the machine where LAPI is running ? HDD ? SSD ?
and I'm not sure where the
The "remote_ip" variable is not set. Defaulting to a blank string. log is coming from, we have nothing like that in crowdsecIt's an EC2 instance Docker host
The remote_ip part comes from the Traefik container's labels in the compose file
I fixed a few of my issues by fixing a storage conflict in the compose but I still have 2 problems
1. When I reboot the host machine I lose access to the dashboard. When I re-run the exact same enroll command it comes back online
2. I'm getting a false-positive that's blocking any IP I go to the site from.
crowdsec-engine | time="2025-09-29T13:17:42-05:00" level=info msg="Ip 68.43.230.130 performed 'LePresidente/http-generic-401-bf' (7 events over 11.289653662s) at 2025-09-29 18:17:42.439658386 +0000 UTC"
crowdsec-engine | time="2025-09-29T13:17:42-05:00" level=info msg="(localhost/crowdsec) LePresidente/http-generic-401-bf by ip 68.43.230.130 (US/7922) : 4h ban on Ip 68.43.230.130"
https://app.crowdsec.net/hub/author/crowdsecurity/configurations/http-generic-bf
Collections, AppSec Rules & Configurations | CrowdSec Hub
Manage collections, configurations, remediation components, and AppSec rules with CrowdSec Hub. Streamline security with tools and integrations for enhanced protection.
Here is a HAR file I took from Chrome when going to our site via Traefik/Crowdsec API. One is for Windows and one is for Mac (the data is the same), you can import it into the F12 menu's Network tab in Chrome, maybe it will give some insight
@blotus any updates on this?
@blotus Bueller?
@Community Manager I think my support agent has abandoned me. I desperately need someone's help on this issue, it's been broken for a month and a half
Its community support we provide it when we can, your issue is hard to replicate as your the only one that seems to have this issue.
When you reboot which dashboard do you mean the console?
Do you see any logs stating an error or is it the console reports it as offline?
If your volume mounts are working correctly the enroll command should throw an error saying "this instance is already enrolled" so I would ensure your mounts are working correctly. For example check
/etc/crowdsec/online_api_credentials.yaml before and after to see if that file changes. If it does change then that's the problem.
For the false positive best to inspect the alert and craft a whitelist expression :
Docs:
https://docs.crowdsec.net/docs/next/log_processor/whitelist/create_expr
https://docs.crowdsec.net/u/getting_started/post_installation/whitelists#expression-pattern
Nextcloud example:
https://app.crowdsec.net/hub/author/crowdsecurity/log-parsers/nextcloud-whitelistApologies for my pushiness, I just hadn't heard back in weeks and i'm totally stuck on this. On the verge of a freak out 😅
When I reboot the Docker host's OS OR restart the container, the crowdsec dashboard at app.crowdsec.net still shows the container's engine as online since it checked for it recently but it will never update its "last activity" time again until I delete the engine in the dashboard then run
docker exec crowdsec-engine cscli enroll <same enroll code as always>. That creates a new engine and things start working after that.
Is the online credentials file where that info gets stored? I can triple check that mount but restarting the container does not change the data inside of the online_api_credentials.yaml fileOkay, so the last activity is linked to when an alert is pushed. So, from the console, if you do not do the deletion and reenrolling, does your alerts mismatch from what you see locally via cscli alerts list and on the console?
Is the online credentials file where that info gets stored? I can triple check that mount but restarting the container does not change the data inside of the online_api_credentials.yaml fileSo, the
last activity in the console tells you when the engine last pushed signal / pulled blocklist or logged in. Check if the last logged in time is updated after you reboot the host.
If cscli enroll does create a new engine, it means that the online_api_credential and/or local_api_credential do get regenerated, and so you have a persistence storage issue.
Please investigate first the last logged in timestamp vs reboot.I persisted the credentials file in my compose explicitly but i'm still getting the same error whenever I restart
volumes:
- /etc/docker/crowdsec/config/acquis.yaml:/etc/crowdsec/acquis.yaml
- /etc/docker/crowdsec/acquis.d/appsec.yaml:/etc/crowdsec/acquis.d/appsec.yaml
- /etc/docker/crowdsec/online_api_credentials.yaml:/etc/crowdsec/online_api_credentials.yaml
- traefik-logs:/var/log/traefik:ro
- crowdsec-db:/var/lib/crowdsec/data/
- crowdsec-config:/etc/docker/crowdsec/
- /etc/localtime:/etc/localtime:ro
Error
crowdsec-engine | time="2025-10-17T15:32:17-05:00" level=error msg="Machine is not enrolled in the console, can't synchronize with the console"
I get this error at the top of my docker logs
credentials files are persisting correctly
Same error about the machine not being enrolled. This is the behavior I see after a reboot until I re-enroll the engine
bump