This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Dump core in k3s Process (ctr) of user 0 dumped core. #7937
Comments
|
It can be
|
|
Jul 10 18:28:44 XXXX systemd[1]: var-lib-rancher-k3s-agent-containerd-tmpmounts-containerd\x2dmount3120126633.mount: Succeeded. Jul 10 18:28:46 XXXX systemd[1]: [email protected]: Succeeded. |
|
coredumpctl -1 debug |
|
How can I help you to debug this? |
|
Can you share the actual core file? It looks like the stack dump analysis of the core file you're getting from If you also had the full journald log from the node around that time, that would probably also be helplful. It looks like there are a lot of weird things going on before the k3s |
audit.log Maybe some secomp problem with the SYSCALL=fcntl |
|
some coredumps |
|
Maybe its CrowdStrike |
|
some more error with perf trace -G k3s.service This part seem interesting: |
|
And some posibility of crowd strike Cyber Fusion Center Dear Apicil team, A new incident has been created by the Cyber Fusion Center. The details for the incident are below: Case reference Date created Category Threat Category Priority Incident Details We can not check the hash to validate if this is malicious or not. XXXX Kudelski Security MSS Kill Chain Analysis Potential Impact Would you need further assistance, please ask the Cyber Fusion Center by using the MSS Portal or by phone: XXXXX Kind regards, |
|
Sure sounds like it. |
|
Maybe its because of my usage of the nginx ingress kubernetes/ingress-nginx#6287 ? @brandond |
|
i try with a fresh install and it does the same ctr root@XXX/tmp [SIGINT]# coredumpctl -1 info |
|
Maybe its ? |
|
Can i have a way to test developement build with containerd |
|
Are you still running Crowdstrike on these nodes? Is it still reporting that it's killing the processes? |
I must have crowdstrike but it don't kill anything since months so maybe it's a bad idea It core dump with secomp so I think it's because of changes in contained that are not upstream yet in k3s |
|
You can always install your own version of containerd and point k3s at it with the --container-runtime-endpoint option. We are looking at updating containerd in the next release: #7986 |
|
Converting this to a discussion as this doesn't seem directly related to a bug in k3s |
github-project-automation
bot
moved this from In Triage
to Done Issue
in K3s Development
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Environmental Info:
k3s version v1.26.6+k3s1 (3b1919b)
go version go1.19.10
Node(s) CPU architecture, OS, and Version:
Red Hat Enterprise Linux release 8.8 (Ootpa)
Linux 4.18.0-477.13.1.el8_8.x86_64 #1 SMP Thu May 18 10:27:05 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration:
single node with etcd without traefik
root@XXXX~# kubectl get nodes
NAME STATUS ROLES AGE VERSION
XXXXXReady control-plane,etcd,master 118d v1.26.6+k3s1
Describe the bug:
Some time i got the ctr process that goes to coredump
/var/lib/rancher/k3s/data/0e6681f4002cdce946827bee7229eb1641dde5036b17cc7dcec1241294a3c52a/bin/k3s
/var/lib/systemd/coredump/core.ctr.0.218dc6d6d4a341d5b11ce9608403af8c.82070.1689001743000000.lz4
coredumpctl -1 info
PID: 81681 (ctr)
UID: 0 (root)
GID: 0 (root)
Signal: 31 (SYS)
Timestamp: Mon 2023-07-10 17:08:59 CEST (1s ago)
Command Line: ctr
Executable: /var/lib/rancher/k3s/data/0e6681f4002cdce946827bee7229eb1641dde5036b17cc7dcec1241294a3c52a/bin/k3s
Control Group: /system.slice/falcon-sensor.service
Unit:
Slice: system.slice
Boot ID: 218dc6d6d4a341d5b11ce9608403af8c
Machine ID: XXXX
Hostname: XXXX
Storage: /var/lib/systemd/coredump/core.ctr.0.218dc6d6d4a341d5b11ce9608403af8c.81681.1689001739000000.lz4
Message: Process 81681 (ctr) of user 0 dumped core.
Steps To Reproduce:
No idea :/
The text was updated successfully, but these errors were encountered: