Open webdock-io opened 1 month ago
@mihalicyn Since you self-assigned I'm hoping this is something which can be looked at and resolved, as we are now seeing this happen on 2 additional systems. What the systems have in common:
Here is a dump from another machine where this happened, not sure if you can tell if this is an identical crash or different. If it's different, let me know and I'll start collecting crash dumps from the various instances so you can get a complete picture:
Hi @webdock-io
Thanks for your report! I'm working on your case right now.
Second one is interesting:
00000000000222fb <proc_read@@Base>:
222fb: f3 0f 1e fa endbr64
222ff: 55 push %rbp
22300: 48 89 e5 mov %rsp,%rbp
22303: 48 83 ec 40 sub $0x40,%rsp
path:
22307: 48 89 7d e8 mov %rdi,-0x18(%rbp)
buf:
2230b: 48 89 75 e0 mov %rsi,-0x20(%rbp)
size:
2230f: 48 89 55 d8 mov %rdx,-0x28(%rbp)
offset:
22313: 48 89 4d d0 mov %rcx,-0x30(%rbp)
fi:
22317: 4c 89 45 c8 mov %r8,-0x38(%rbp)
rax = fi
2231b: 48 8b 45 c8 mov -0x38(%rbp),%rax
rax: fi
rax = *(rax + 16) = fi->fh
2231f: 48 8b 40 10 mov 0x10(%rax),%rax
rax: fi->fh
*(rbp-8)=rax ( <=> ( f = fi->fh ) )
22323: 48 89 45 f8 mov %rax,-0x8(%rbp)
rbp: 7c38241ffae0
rax = *(rbp - 8)
22327: 48 8b 45 f8 mov -0x8(%rbp),%rax
rax: 0000000000008000 (invalid pointer!)
eax = *(rax+0x18)=*(rax+16+8) = f->type
2232b: 8b 40 18 mov 0x18(%rax),%eax <=== BOOM!
offset 2232b <-> virtual address 7c3824d0532b
It looks like for some reason, fi->fh
value is wrong (https://github.com/lxc/lxcfs/blob/62c723047ffc7784b097321dd6a7ce893b43a01a/src/proc_fuse.c#L1645).
I'm continuing investigation.
@mihalicyn That's amazing! Much appreciated.
I will collect crash dumps from other hosts where this has happened, I think we have seen this across 4 hosts thus far, and post them here when I have the chance - in case they are somehow different from what you've seen here already.
Cheers :)
Here are the remainder of crash dumps we've seen so far, so you can check if this is the same or different.
Hm, interesting. All 3 cases are a bit different, but root cause is the same. Invalid value of INTTYPE_TO_PTR(fi->fh)
.
@webdock-io can you please show uname -a
? Have you recently updated your kernel?
Sure - all our instances with the issue are identical to this:
Linux lxdvm2-x14-u26-r1 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
all our instances with the issue are identical to this:
Did this problem appear recently? After a kernel upgrade? Or after LXD upgrade? (or both?..)
Well yes and no... These are not old / upgraded systems.. they are all brand new. All our newly deployed systems are on Noble and the latest kernel and latest stable lxd version.
These are also systems where we are running containers inside VMs which we haven't done before
So this is all new and the first time we run significant number of containers and load on these new systems
We are not seeing this on any of our old systems
We did do a lot of load testing before deployment and didn't see this happen. But we may have missed it as we weren't actively looking at lxcfs, rather at system stability
@webdock-io thanks for providing an extra context on this ;-)
Can you try to collect a crash dump from the LXCFS?
All you need to do is (as root):
echo '|/bin/sh -c $@ -- eval exec cat > /var/crash/core-%e.%p' > /proc/sys/kernel/core_pattern
and wait until a next crash. Then collect a crashdump file in /var/crash/
directory and share it with me.
(you can GPG encrypt it if you want with my key gpg --encrypt your_core_dump --recipient alexander@mihalicyn.com
)
Hello. We have now run the command on all thus-far affected systems. If it happens again in the same location(s) we will have a dump for you
Small update: I'm really not sure we will see this type of crash again. We identified a config issue on our systems where our ZFS ARC cache limit was set way too low. This was causing abnormally high IOWAIT on our systems which seems to have been the root cause of our problems (we were also seeing system halts/crashes). After we upped our ARC cache limit to something more reasonable, we see really good behavior everywhere and thus far no lxcfs or system crashes.
This may point to something on the systems or in the kernel, due to the io bottleneck, getting messed up. It's only been a couple of days since we made this change, so the issue may not be completely solved - but so far it's looking good. We will be keeping the crash dump collection flag turned on and will of course revert here if we see it happening again.
Thank you for your time
We identified a config issue on our systems where our ZFS ARC cache limit was set way too low. This was causing abnormally high IOWAIT on our systems which seems to have been the root cause of our problems (we were also seeing system halts/crashes).
Even when IOWAIT times are high, crashes are still crashes and we should fix it. So, you have a workaround but issue is still there. So I would not ignore it, and I would try to revert this workaround and try to get a reproduction and a crashdump so we can try to figure out what is wrong from the LXCFS/libfuse/kernel side which leads to a crashes like you've seen before.
we were also seeing system halts/crashes
so, not only LXCFS was crashing? What else was crashing then?
Hello. Yes I agree, crashes are still crashes. I think it may be difficult to get a reproducer on this, but we will have a system free soon where I can attempt to recreate the issue for you, but no guarantees.
so, not only LXCFS was crashing? What else was crashing then?
I do not want to confuse the matter. This was more of a statement that we saw other things misbehaving, namely our virtual machines. As mentioned earlier we are running these workloads inside LXD VMs - so, nested LXD if you will. Here we saw the VMs hang - no crash output, nothing in syslog no explanation that we could find, the VM would just go into a halt state and we would need to restart it to get it operational again. This did not coincide with the lxcfs crashes we saw, so they are not related per se but the root cause was the same, we think.
After we made the ARC cache happy and alleviated the bottleneck, we have not seen such a crash in 48+ hours now, where before we saw 1-2 crashes every 24 hours. So we are hopeful we have mitigated that issue as well. Although, a full VM crash is worrying to say the least, and as is the case with the lxcfs crash we haven't really fixed the issue, we've just resolved what was provoking the issue (we think/hope)
Hello
We have now seen this happen on a completely new host, which had our "workaround" implemented. So this crash is still happening and is still real. However, we have had to remove your crash dump reporting flag from the hosts where we did have it activated as it was filling up our disk! We are a public cloud hosting lxd container instances, and whatever crashes were happening in customer containers were being dumped to /var/crash. Not only did this create a lot of crash dumps on some hosts, worse it was quickly filling up disk on some systems. We caught it in time and averted disaster - but we simply cannot allow this crash dumping to be active on production systems.
So... In order to try and procure a crash dump for you, we have dedicated an instance to this purpose where we are stressing it a lot. We hope this will provoke a crash sometime in the next 24-48 hours - if not, then I'm not sure what we can do as then it seems synthetic workloads will not do the trick... We will see.
Anyway, here is the latest crash on an otherwise healthy system, so you can see if it's the same (I'm thinking it is)
@mihalicyn Here is another case for you. I dont want to be reporting the same crash over and over, but I'm reporting this one as it's different somehow. So, we have "detection" of crashes which just consists of us checking if the lxcfs process is running with pgrep lxcfs
. Now, we were made aware by a customer something was wrong just now, and checking we see lxcfs is not functioning properly and we do see the below crash in the syslog. However, we not only see lxcfs running in our process list, but we have two instances running. I have no idea if that is something that is possible/expected to happen and I find it strange lxcfs hasn't completely died/gone away like with the other crashes we've seen. This is what ps aux
shows:
$ ps aux | grep lxcfs
root 2142417 0.0 0.0 7076 2016 pts/1 S+ 13:52 0:00 grep --color=auto lxcfs
root 2599964 0.2 0.0 451664 2304 ? Sl Jun11 3:43 lxcfs --enable-loadavg /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
root 2733049 0.6 0.0 675464 2592 ? Sl Jun11 8:48 lxcfs --enable-loadavg /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
In my mind, very odd behavior in this case. We checked on further hosts, and we actually have one more host which has two instances of lxcfs running, but there it seems OK and doing its job. We are not sure what to make of this. Here is the relevant crash dump:
One last addendum here @mihalicyn we are also the guys running everything under cgroupv1, because of this: https://github.com/lxc/lxcfs/issues/538
I dont know if that has any bearing on the issue, but we thought it was relevant to mention this.
Edit: We can give you access to a test environment if you want to inspect some things or test something out. Just send us your public key at support@webdock.io and we will give you access. Thanks very much for your time. This issue is unfortunately becoming rather painful for us, so we really hope you can find time to check this further if you can. Fingers crossed :)
@webdock-io thanks for providing an extra context on this ;-)
Can you try to collect a crash dump from the LXCFS?
All you need to do is (as root):
echo '|/bin/sh -c $@ -- eval exec cat > /var/crash/core-%e.%p' > /proc/sys/kernel/core_pattern
and wait until a next crash. Then collect a crashdump file in
/var/crash/
directory and share it with me. (you can GPG encrypt it if you want with my keygpg --encrypt your_core_dump --recipient alexander@mihalicyn.com
)
@mihalicyn is there a way where we can limit core dumps to disk to only happen if lxcfs crashes and not other stuff? If so we would be able to enable this infrastructure-wide and catch this for sure... We tried looking around for info on this, but it's unclear how to achieve this exactly..if you know how, that would help
So... In order to try and procure a crash dump for you, we have dedicated an instance to this purpose where we are stressing it a lot. We hope this will provoke a crash sometime in the next 24-48 hours - if not, then I'm not sure what we can do as then it seems synthetic workloads will not do the trick... We will see.
We have now absolutely hammered a system for more than 24 hours with high load on cpu, memory, io and sirq. We nerfed our Arc cache and had 3 container instances doing a lot of activity. And.... Nothing. lxcfs runs fine, no crash of our VM
So, we are unable to reproduce this synthetically it seems. Maybe we just need a lot more containers... An idea could be to spin up 100+ containers and have them all do... something.
@mihalicyn Maybe to help us get a reproducer here, can you tell us if the crashing codepath relates to some specific virtualization in lxcfs? For example, if the code is tied to CPU or memory or whichever specific subsystem? Because then we could focus on creating diverse workloads against just that system, instead of hammering everything all at once.
Anyway, we await your feedback here :)
Hi, @webdock-io
@mihalicyn is there a way where we can limit core dumps to disk to only happen if lxcfs crashes and not other stuff? If so we would be able to enable this infrastructure-wide and catch this for sure... We tried looking around for info on this, but it's unclear how to achieve this exactly..if you know how, that would help
You can try something like that:
/root/core_dump.sh
file with the following content:
# cat /root/core_dump.sh
#!/bin/sh
PROC_NAME=$1 PROC_PID=$2
[ "${PROC_NAME}" != "lxcfs" ] && exit 0
cat /dev/stdin | gzip --fast > /var/crash/core-${PROC_NAME}.${PROC_PID}.gz
2. `chmod +x /root/core_dump.sh`
3.
cat /proc/sys/kernel/core_pattern > /root/core_pattern.old_value.bak
echo '|/root/core_dump.sh %e %p' > /proc/sys/kernel/core_pattern
Edit: We can give you access to a test environment if you want to inspect some things or test something out. Just send us your public key at support@webdock.io and we will give you access. Thanks very much for your time. This issue is unfortunately becoming rather painful for us, so we really hope you can find time to check this further if you can. Fingers crossed :)
This is a good option. Let's try to get some core dump with the method I've described above (with filtering) and if it doesn't work then giving me an access would be a last hope weapon.
One last addendum here @mihalicyn we are also the guys running everything under cgroupv1, because of this: #538
Ugh, that's painful. Because at some point cgroupv1 become deprecated in upstream, or even earlier, in systemd and you will have no chance to stay on it. I believe we should sort out this blocker that prevents you from the migration to cgroup-v2. It's extremely important. Let's discuss this in #538
@mihalicyn Maybe to help us get a reproducer here, can you tell us if the crashing codepath relates to some specific virtualization in lxcfs? For example, if the code is tied to CPU or memory or whichever specific subsystem? Because then we could focus on creating diverse workloads against just that system, instead of hammering everything all at once.
That's a good question. Actually, I tend to believe that crash happens not because of an issue in LXCFS, but likely it's a stack corruption somewhere in libfuse or even a kernel problem. And to investigate this deeper I need to have a memory dump of the LXCFS process (ideally, a few different ones).
@webdock-io I have edited your messages a bit and put all the crash data content inside a special markup:
<details><summary>Crash data</summary>
...
</details>
this makes this issue thread a bit more readable for others :)
@mihalicyn Thank you for the markup tip
Ugh, that's painful. Because at some point cgroupv1 become deprecated in upstream, or even earlier, in systemd and you will have no chance to stay on it. I believe we should sort out this blocker that prevents you from the migration to cgroup-v2. It's extremely important. Let's discuss this in https://github.com/lxc/lxcfs/issues/538
I am very happy you see this as important, because it is! We were starting to have the discussion internally whether we should migrate over to KVM entirely and completely drop container VPS support, as this issue would be a complete blocker for proper container support in the near-future. Now that we know that this issue is being worked on, we will hold off on pressing the panic button anytime soon :)
We are unfortunately still seeing occasional crashes as you know, and had one last night. Unfortunately we had not had the time to implement your new crash dump code. This will be done today on all our hosts, and I am confident we will have one or more crash dumps for you within the next few days.
Thank you for your continued assistance and we will revert here once we have more material for you.
@mihalicyn We have a crash dump for you! However...
you can GPG encrypt it if you want with my key gpg --encrypt your_core_dump --recipient alexander@mihalicyn.com
This command looks a bit wrong and I tried a few things but I am unable to encrypt the dump for you. It looks to me you expect me to find your pubkey somewhere? I really tried my best reading the man page for gpg and looking around to see if I could find your pubkey somewhere but I am unable. Please provide more idiot-proof steps for me here, and I'll get this encrypted and placed somewhere you can grab it asap :)
Thanks!
@mihalicyn After much much faffing around I finally found your gpg key at keyserver.ubuntu.com and imported it with gpg --keyserver keyserver.ubuntu.com --recv-keys 0x801a2056d5cf7ecf6679a79bf9fe8fed56c36d56
Anyway, here is the encrypted crash dump attached. I'll post further crash dumps as they come in :) I really hope this helps you find the issue! core-lxcfs.1499342.gpg.gz
Edit: Github would not accept .gpg exension for uploads, so I just renamed the file and reversed the extension so github would eat it. You should rename it to .gz.gpg before decrypting and then decompressing
@mihalicyn And here is new one from another host
Hi @webdock-io !
After much much faffing around I finally found your gpg key at keyserver.ubuntu.com and imported it with
Sorry about not providing you with a more detailed instruction. It was an optional step to encrypt it, but you did it right!
Thanks for providing me with your coredumps, I'm on it to investigate this issue.
Hello @mihalicyn
We now have two more crash dumps for you:
core-lxcfs.2897.gpg.gz core-lxcfs.3396.gpg.gz
Any progress on this issue so far?
@webdock-io @mihalicyn
I'm facing this too I think as I noticed all the 4 cores of my host visible in one of my containers but for some reason I restarted my host and all looks good now. I too placed the logging mechanism, will let you guys know if I see a crash again. And let me know if you guys need any information from me.
Thanks.
Hi @webdock-io
I posted analysis (for those who interested in these details) at the end of this message.
First of all, thanks for helping us and providing core dumps. This is crucial.
I think that we need to go even further with this and provide you with some special debug builds of LXCFS which can allow us to catch the issue. I'll think about a proper way to do so, of course, I can't just provide you with the binary and ask you to run it. It's just not how we do things. :) Likely, I'll prepare some special branch of LXCFS and instructions how to build it on your infrastructure and deploy.
Also, please, can you tell me if you have any special or unusual software in containers on your infrastructure that can affect LXCFS? May be, you are using some monitoring system agent like node_exporter or something like that. Because you have a stable reproducer, if I would have such a stable reproducer things would be much-much easier to solve.
Hi @mihalicyn
Amazing work so far, but concerning that it's outside of lxcfs seemingly and thus potentially has deeper roots. Any wholesale lxcfs debug deployment would only be feasible if we can do so without a reboot of the hosts, as otherwise we'd have to deploy it whenever a host crashes anyway (which is unfortunately not rare these days, explanation to follow) - but let's see what you come up with and how we can best achieve this.
Some information for you to go on:
apt install -y --install-recommends linux-generic-hwe-24.04
apt install -y zfsutils-linux apparmor ubuntu-standard bridge-utils htop nano lftp fail2ban git ntp ntpdate pigz php7.4-cli php7.4-curl php7.4-mbstring pwgen build-essential libboost-all-dev cmake iotop mbuffer snapd molly-guard tcptrack smartmontools net-tools iftop screen stress cpu-checker numactl iptables-persistent
We install lxd using snap, of course.
Now, from what we can tell this crash happens on hosts which are using some amount of disk i/o - without fully understanding your analysis it seems the crash is related to disk i/o or am i mistaken?
If it is, then what we're also seeing these days after migrating to latest kernel/Noble is occasional kernel crashes with no output in syslog or kern log other than null bytes - we have tracked this down to be very strongly correlated with the zfs arc cache and heavy read workloads. Essentially speaking, as long as the ARC RAM cache is not full and zfs can cache reads in memory things are fine - as soon as the ARC cache is filled and if the heavy read workloads continue, thus causing zfs to hit disk a lot, we get a kernel panic.
This is admittedly a more serious issue for us and we are doing our best to mitigate by spreading workloads across our infrastructure and allowing zfs to use obscene amounts of ARC cache. I thought I'd mention this issue as maybe it's related. However, we are seeing these kernel crashes on bare metal as well as vm's and these kernel crashes do not coincide with lxcfs crashes in any meaningful way, which happen on relatively calm systems also. So yeah, not directly related but maybe relevant not sure, as we have a feeling that lxcfs is crashing a lot less now that we've increased our ARC cache across our entire infrastructure.
Please let me know if there is any further, more specific information, you need. I would not say that we have a reliable reproducer per se, other than "this is happening fairly frequently" :)
All the crashing lxcfs thus far has been on systems where we are running lxd containers inside LXD KVM virtual machines, so nested containers so to speak. We have yet to see lxcfs crash on systems where it's running on bare metal.
Ow! This is very-very important fact. Just to ensure that I understood you right. All LXCFS crashes happened only inside the VM instances. You have not seen any crashed on bare metal hosts yet. Right?
Now, from what we can tell this crash happens on hosts which are using some amount of disk i/o - without fully understanding your analysis it seems the crash is related to disk i/o or am i mistaken?
One of crashes happened on the read of /proc/diskstats
file, but it does not mean that crash itself somehow related to I/O activity.
Interesting thing here is that all these crashes are somehow similar and at the same time different. There is nothing in common from the LXCFS perspective. Different files like /proc/stat
, /proc/diskstats
. Different operations: release, read. At the same time, in all cases we see an inconsistent memory state. What is the most weird is that each time traces go to a fuse file handle...
If it is, then what we're also seeing these days after migrating to latest kernel/Noble is occasional kernel crashes
This is painful. And, for sure, this is a priority 1 to fix. I would suggest to enable kdump to collect a coredump files for the kernel so you can report these crashes to the Ubuntu kernel maintainers. Please, refer to https://ubuntu.com/server/docs/kernel-crash-dump (feel free to ask me if you have any questions).
Essentially speaking, as long as the ARC RAM cache is not full and zfs can cache reads in memory things are fine - as soon as the ARC cache is filled and if the heavy read workloads continue, thus causing zfs to hit disk a lot, we get a kernel panic.
Hm, just in case, of course, you have tested your RAM modules with memtest+, disk SMARTs are fine too.
I would say that this can be a sign of a very serious problem in the kernel. ZFS, while being a piece of art in software engineering, is an out-of-tree Linux kernel module, which brings additional risks because OpenZFS developers have to adapt it to each kernel version and errors are not excluded there. It can be a misuse of API because of API changes in the upstream kernel and so on. Which can lead to memory leaks, use-after-free errors, OOB r/w and so on. As a consequence, it may corrupt your kernel memory state and make you system to behave in extremely unexplainable ways. Even things which are not directly connected to ZFS or filesystems or disk I/O can start to break due to memory corruption (when a buggy code writes to a memory region which does not belong to it).
However, we are seeing these kernel crashes on bare metal as well as vm's and these kernel crashes do not coincide with lxcfs crashes in any meaningful way, which happen on relatively calm systems also.
Memory corruption is a random thing. For example, one time it can override a memory structure of a "not important" (there is no unimportant things in the kernel ;-)) thing and you won't see any visible effects. At the same time, next time memory corruption can shot in a more important memory area which will be noticed immediately, because of crash of some process or VM or even the entire system.
So yeah, not directly related but maybe relevant not sure, as we have a feeling that lxcfs is crashing a lot less now that we've increased our ARC cache across our entire infrastructure.
And this is a very important observation. It can be that ZFS somehow corrupts memory and when you decreased a memory corruption rate LXCFS started to crash less often too.
To conclude, I would suggest to:
May be related to https://github.com/openzfs/zfs/issues/16187
Hi @capriciousduck !
Thanks for reporting this!
I'm facing this too I think as I noticed all the 4 cores of my host visible in one of my containers but for some reason I restarted my host and all looks good now.
Please, can you tell me the following info from your system:
cat /etc/os-release
uname -a
lsmod
also, are you using just LXC+LXCFS or LXD or Incus?
Ow! This is very-very important fact. Just to ensure that I understood you right. All LXCFS crashes happened only inside the VM instances. You have not seen any crashed on bare metal hosts yet. Right?
That's correct. As of yet lxcfs crashes have only happened inside VMs and not on bare metal yet
This is painful. And, for sure, this is a priority 1 to fix. I would suggest to enable kdump to collect a coredump files for the kernel so you can report these crashes to the Ubuntu kernel maintainers. Please, refer to https://ubuntu.com/server/docs/kernel-crash-dump (feel free to ask me if you have any questions).
We looked into this, and the more we looked the more daunting this became. It is by no means as simple as shown in the Ubuntu docs it seems, and we ended up studying this guide in detail: https://hackmd.io/@0xff07/S1ASmzgun
And we concluded that the difficulty in setting this up, and difficulty in reading the dumps (although, maybe we wouldn't actually need to read these ourselves, but rather pass this on to more knowledgeable persons) really discouraged us to even try. Not to mention this requires a reboot before it's even active, which is nothing we can/will do (unless a system has already crashed and we need to reboot anyway....)
I guess we could attempt this, so that this is "ready" so that once a system needs a reboot anyway, from then on it will be active and then... We would see. If you can illuminate this for us / give us some pointers on how to get this set up I'd be willing to give it a shot.
Hm, just in case, of course, you have tested your RAM modules with memtest+, disk SMARTs are fine too.
This is all brand new systems with ECC RAM throughout and new drives with no SMART errors. We did run 24-48 hour high load testing where we stressed memory before deploying into production, which has always been enough/succesful in detecting bad RAM in our past experience.
Not to mention these issues have happened across a wide range of hosts (and even platforms, Ryzen vs. Intel Xeon) so we are pretty confident this is not hardware related in any way.
I would say that this can be a sign of a very serious problem in the kernel. ZFS, while being a piece of art in software engineering, is an out-of-tree Linux kernel module, which brings additional risks because OpenZFS developers have to adapt it to each kernel version and errors are not excluded there. It can be a misuse of API because of API changes in the upstream kernel and so on. Which can lead to memory leaks, use-after-free errors, OOB r/w and so on. As a consequence, it may corrupt your kernel memory state and make you system to behave in extremely unexplainable ways. Even things which are not directly connected to ZFS or filesystems or disk I/O can start to break due to memory corruption (when a buggy code writes to a memory region which does not belong to it).
Yes I agree from the information you have given us here and from what we've seen, this really smells like memory corruption caused by ZFS.
To conclude, I would suggest to:
- enable kdump (to collect kernel crashes)
- try to experiment with different kernel versions (pick an older one on some nodes to see if situation changes)
Maybe you could save us some research time and/or mistakes, if you can show us the steps on how to safely revert the kernel version? We have never done this, we have only ever upgraded the kernel :D
May be related to openzfs/zfs#16187
We found this issue as well in our research and felt it was very similar to our case! Although, we have been running with pretty recent kernels and zfs versions newer than the one reported in that issue, in production for a long time, and saw none of these crashes before - so we really don't know if this is the same or not. It's really only when we deployed systems with the latest Noble kernel and the zfs that comes with it, zfs-2.2.2-0ubuntu9, that we started seeing this.
And we concluded that the difficulty in setting this up, and difficulty in reading the dumps (although, maybe we wouldn't actually need to read these ourselves, but rather pass this on to more knowledgeable persons) really discouraged us to even try.
It is definitely worth it. As having a coredump will allow us to at least identify a callstack and report the issue properly (who knows, may be it's a known issue). As for reading a dump, don't worry, you can share it with me I'll help with that.
Maybe you could save us some research time and/or mistakes, if you can show us the steps on how to safely revert the kernel version? We have never done this, we have only ever upgraded the kernel :D
If you are using Noble, it looks like there is no choice. As 6.8 is a main kernel Noble released with. In this case you can try to deploy upstream kernel version + upstream ZFS 2.2.4 (https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html#debian-and-ubuntu). ZFS update from 2.2.2 -> 2.2.4 should be pretty safe as it's minor and bugfix release. I don't know why zfs package in Ubuntu Noble is still on 2.2.2...
Maybe, it's better to try to build newer ZFS and deploy it to see if it helps. And if not, then go for an upstream kernel versions (for example, https://kernel.ubuntu.com/mainline/v6.8.12/).
You could try my mainline packages to get a clean upstream kernel (no Ubuntu changes) but still built with a config that's very close to the Ubuntu one.
To do so, you'll need to:
It is definitely worth it. As having a coredump will allow us to at least identify a callstack and report the issue properly (who knows, may be it's a known issue). As for reading a dump, don't worry, you can share it with me I'll help with that.
Thanks so much @mihalicyn that is amazing. We will proceed to, at least perform the intial steps before the reboot, on all our hosts today, so they are somewhat ready to collect crash dumps. We have a single system which crashed again last night (after having crashed two times in the previous 12 hours, so a system in a pretty flaky state) where we fully enabled this, but there we also took some mitigation steps such as upgrading to the latest kernel (from 6.8.0-31 to 6.8.0-36), moving some high i/o users away and increasing the ARC cache even further. So it's not certain this system will crash again and provide a dump for us.
I will of course ping you as soon as such a dump is produced.
As to the suggestion from @mihalicyn to try zfs-dkms - we've for other reasons installed zfs-dkms in the past and now we have some systems on a legacy part of our infrastructure which has this issue: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/2044630
As it's really not recommended to install zfs-dkms and seemingly if left for "too long" it can cause problems down the line where removing it is seemingly fraught with potential danger and would involve downtime for customers for sure, we are really hesitant to do something like this. Ideally we'd stay on official Ubuntu kernels and do things "the recommended way"
Which leads me to the suggestion from @stgraber - this also strikes me as potentially dangerous in a couple of ways, firstly it is unclear to me whether we could easily revert to an official kernel with the built-in zfs support down the line. What if Stephane gets hit by a bus and no longer able to maintain the Zabbly builds? When would we know for sure official Ubuntu kernel is safe to switch back to? I really do appreciate the suggestion @stgraber but without further insight (and a proper plan) I am currently very hesitant to do something like this. With that said, I have reached out to you directly by email and I hope we can have a further chat about this in the coming days if you have time.
So, for right now what we are doing is preparation and mitigation steps where we:
Anything beyond that will have to be the subject of further analysis, as we can't just willy-nilly go to "experimental" kernels with associated reboots and downtime for customers time and again :(
I have a followup question for you guys
We are deploying a number of new host machines next week on our infrastructure. This gives us the opportunity to do things differently, and hopefully deploy unaffected systems, which could be "safe havens" to migrate customers to which are triggering the issue on the unstable part of our infrastructure. Would we benefit from basing these systems on Ubuntu Jammy instead of Noble? Or would we just be getting the latest kernel/zfs modules, the same as for Noble, anyway and be in the same situation?
I guess Jammy would give us better opportunity to run with an older kernel, say the latest kernel version we know was succesful in production before. I guess what I am asking is, what would you do in this situation? Any input / knowledge here would be appreciated :)
Ubuntu Noble LXD v5.21.1 LTS + whatever version of lxcfs is packaged with this
We have a system with about 86 containers and no significant activity, a bit of load but nothing major. Out of our fleet of 60+ hosts which are pretty much identical to this system with some thousands of containers; on this host lxcfs crashes every couple of days. We have checked all logs we can think of, but all we can find is the crash dump itself in the syslog, as seen below.
Any help diagnosing these crashes is much appreciated, we suspect it's tied to some "unique" customer workload as it's only happening here. It's really rather painful having to reboot the entire host and bring down all instances with it, whenever this happens.
Crash data
``` 2024-06-05T14:07:40.930342+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: *** signal 11 2024-06-05T14:07:40.930748+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: Register dump: 2024-06-05T14:07:40.930813+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RAX: 00000007d89ac102 RBX: ffffffffffffff80 RCX: 00007d8a0e27d769 2024-06-05T14:07:40.930860+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RDX: 00007d89ed5ffc90 RSI: 00000007d89ac0f2 RDI: 00000007d89ac102 2024-06-05T14:07:40.930920+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RBP: 00007d89ed5ffb20 R8 : 00007d8a0e262198 R9 : 000000000000000f 2024-06-05T14:07:40.930972+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: R10: 00007d8a0e262198 R11: 0000000000000000 R12: 0000000000000003 2024-06-05T14:07:40.931016+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: R13: 00007d8978107df0 R14: 00006437266e5708 R15: 0000000000000000 2024-06-05T14:07:40.931059+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RSP: 00007d89ed5ffad0 2024-06-05T14:07:40.931119+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RIP: 00007d8a0e3493fe EFLAGS: 00010202 2024-06-05T14:07:40.931163+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: CS: 0033 FS: 0000 GS: 0000 2024-06-05T14:07:40.931230+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: Trap: 0000000e Error: 00000004 OldMask: 00004007 CR2: d89ac0fa 2024-06-05T14:07:40.931282+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000 2024-06-05T14:07:40.931336+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: RIP: 00000000 RDP: 00000000 2024-06-05T14:07:40.931379+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000 2024-06-05T14:07:40.931430+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000 2024-06-05T14:07:40.931479+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000 2024-06-05T14:07:40.931529+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000 2024-06-05T14:07:40.931578+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: mxcsr: 1fa0 2024-06-05T14:07:40.931628+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM0: 00000000000000000000000000000000 XMM1: 00000000000000000000000000000000 2024-06-05T14:07:40.931700+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM2: 00000000000000000000000000000000 XMM3: 00000000000000000000000000000000 2024-06-05T14:07:40.931743+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM4: 00000000000000000000000000000000 XMM5: 00000000000000000000000000000000 2024-06-05T14:07:40.931794+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM6: 00000000000000000000000000000000 XMM7: 00000000000000000000000000000000 2024-06-05T14:07:40.931958+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM8: 00000000000000000000000000000000 XMM9: 00000000000000000000000000000000 2024-06-05T14:07:40.932017+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000 2024-06-05T14:07:40.932066+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000 2024-06-05T14:07:40.932115+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000 2024-06-05T14:07:40.932164+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: Backtrace: 2024-06-05T14:07:40.932228+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /lib/x86_64-linux-gnu/libc.so.6(free+0x1e)[0x7d8a0e3493fe] 2024-06-05T14:07:40.932285+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/liblxcfs.so(do_release_file_info+0x42)[0x7d8a0e2880c8] 2024-06-05T14:07:40.932335+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/liblxcfs.so(proc_release+0x20)[0x7d8a0e27d789] 2024-06-05T14:07:40.932385+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: lxcfs(+0x2f2c)[0x64372561cf2c] 2024-06-05T14:07:40.932434+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: lxcfs(+0x3c7f)[0x64372561dc7f] 2024-06-05T14:07:40.932708+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/x86_64-linux-gnu/libfuse3.so.3(+0xbb6a)[0x7d8a0e4fbb6a] 2024-06-05T14:07:40.932765+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/x86_64-linux-gnu/libfuse3.so.3(+0x104fa)[0x7d8a0e5004fa] 2024-06-05T14:07:40.932801+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/x86_64-linux-gnu/libfuse3.so.3(+0x11738)[0x7d8a0e501738] 2024-06-05T14:07:40.932892+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/x86_64-linux-gnu/libfuse3.so.3(+0x1e13f)[0x7d8a0e50e13f] 2024-06-05T14:07:40.932957+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /snap/lxd/current/lib/x86_64-linux-gnu/libfuse3.so.3(+0x167a7)[0x7d8a0e5067a7] 2024-06-05T14:07:40.933000+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /lib/x86_64-linux-gnu/libc.so.6(+0x94ac3)[0x7d8a0e338ac3] 2024-06-05T14:07:40.933043+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: /lib/x86_64-linux-gnu/libc.so.6(+0x126850)[0x7d8a0e3ca850] 2024-06-05T14:07:40.933091+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: Memory map: 2024-06-05T14:07:40.933142+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 64372561a000-643725622000 r-xp 00000000 07:01 44 /snap/lxd/28463/bin/lxcfs 2024-06-05T14:07:40.933216+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 643725622000-643725623000 r--p 00007000 07:01 44 /snap/lxd/28463/bin/lxcfs 2024-06-05T14:07:40.933275+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 643725623000-643725624000 rw-p 00008000 07:01 44 /snap/lxd/28463/bin/lxcfs 2024-06-05T14:07:40.933325+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 6437266d8000-643726727000 rw-p 00000000 00:00 0 [heap] 2024-06-05T14:07:40.933361+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d88f8000000-7d88f8203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933404+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d88f8203000-7d88fc000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.933447+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8900000000-7d8900204000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933502+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8900204000-7d8904000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.933551+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8904000000-7d8904203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933600+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8904203000-7d8908000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.933705+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d890c000000-7d890c203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933765+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d890c203000-7d8910000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.933817+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8910000000-7d8910213000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933859+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8910213000-7d8914000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.933908+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8918000000-7d8918206000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.933957+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8918206000-7d891c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934015+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d891c000000-7d891c21d000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934064+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d891c21d000-7d8920000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934121+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8924000000-7d8924177000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934169+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8924177000-7d8928000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934245+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8928000000-7d8928172000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934294+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8928172000-7d892c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934351+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8930000000-7d8930203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934400+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8930203000-7d8934000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934449+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8934000000-7d8934165000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934507+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8934165000-7d8938000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934557+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d893c000000-7d893c17b000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934598+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d893c17b000-7d8940000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934674+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8940000000-7d894016d000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934732+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d894016d000-7d8944000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934789+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8948000000-7d8948207000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.934838+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8948207000-7d894c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.934950+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d894c000000-7d894c203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.935009+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d894c203000-7d8950000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.935723+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8954000000-7d8954203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.935778+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8954203000-7d8958000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.935824+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8958000000-7d895820d000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.935875+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d895820d000-7d895c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.935921+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8960000000-7d8960178000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.935971+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8960178000-7d8964000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936030+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8964000000-7d8964203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936087+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8964203000-7d8968000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936133+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d896c000000-7d896c21a000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936178+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d896c21a000-7d8970000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936247+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8970000000-7d8970204000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936293+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8970204000-7d8974000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936343+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8978000000-7d8978203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936395+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8978203000-7d897c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936446+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d897c000000-7d897c203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936497+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d897c203000-7d8980000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936547+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8984000000-7d898417e000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936597+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d898417e000-7d8988000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936660+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8988000000-7d8988203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936712+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8988203000-7d898c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936763+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8990000000-7d8990203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936818+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8990203000-7d8994000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936875+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8994000000-7d8994203000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.936930+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8994203000-7d8998000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.936975+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d899c000000-7d899c204000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937025+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d899c204000-7d89a0000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937070+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89a0000000-7d89a0172000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937115+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89a0172000-7d89a4000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937165+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89a8000000-7d89a8205000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937226+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89a8205000-7d89ac000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937290+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ac000000-7d89ac17b000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937341+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ac17b000-7d89b0000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937397+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89b4000000-7d89b416f000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937448+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89b416f000-7d89b8000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937504+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89b8000000-7d89b8173000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937554+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89b8173000-7d89bc000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.937610+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89c0000000-7d89c0178000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.937983+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89c0178000-7d89c4000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938046+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89c4000000-7d89c417a000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938134+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89c417a000-7d89c8000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938191+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89cc000000-7d89cc204000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938255+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89cc204000-7d89d0000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938306+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89d0000000-7d89d0181000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938363+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89d0181000-7d89d4000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938409+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89d8000000-7d89d8170000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938459+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89d8170000-7d89dc000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938504+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89dc000000-7d89dc173000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938556+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89dc173000-7d89e0000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938602+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e2c00000-7d89e2c01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938670+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e2c01000-7d89e3401000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938707+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e4000000-7d89e4178000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938742+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e4178000-7d89e8000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938784+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e8000000-7d89e8173000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938813+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89e8173000-7d89ec000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938848+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ece00000-7d89ece01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938882+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ece01000-7d89ed601000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938916+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ee200000-7d89ee201000 ---p 00000000 00:00 0 2024-06-05T14:07:40.938950+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ee201000-7d89eea01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.938984+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89eec00000-7d89eec01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939019+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89eec01000-7d89ef401000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939052+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ef600000-7d89ef601000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939086+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89ef601000-7d89efe01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939120+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f0000000-7d89f016b000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939148+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f016b000-7d89f4000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939182+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f4000000-7d89f4177000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939231+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f4177000-7d89f8000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939266+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f8e00000-7d89f8e01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939308+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89f8e01000-7d89f9601000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939346+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89fa200000-7d89fa201000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939387+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89fa201000-7d89faa01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939421+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89fc000000-7d89fc16c000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939455+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d89fc16c000-7d8a00000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939490+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a00000000-7d8a00175000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939533+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a00175000-7d8a04000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939567+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a04400000-7d8a04401000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939596+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a04401000-7d8a04c01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939630+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a04e00000-7d8a04e01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939680+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a04e01000-7d8a05601000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939716+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a05800000-7d8a05801000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939762+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a05801000-7d8a06001000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939824+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a06c00000-7d8a06c01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939867+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a06c01000-7d8a07401000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939901+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a07600000-7d8a07601000 ---p 00000000 00:00 0 2024-06-05T14:07:40.939935+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a07601000-7d8a07e01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.939975+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a08000000-7d8a08067000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940029+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a08067000-7d8a0c000000 ---p 00000000 00:00 0 2024-06-05T14:07:40.940074+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0c600000-7d8a0c601000 ---p 00000000 00:00 0 2024-06-05T14:07:40.940115+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0c601000-7d8a0ce01000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940149+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0d000000-7d8a0d001000 ---p 00000000 00:00 0 2024-06-05T14:07:40.940185+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0d001000-7d8a0d801000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940236+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0d9e3000-7d8a0da00000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940265+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0da00000-7d8a0da01000 ---p 00000000 00:00 0 2024-06-05T14:07:40.940306+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0da01000-7d8a0e201000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940340+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e201000-7d8a0e261000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940376+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e261000-7d8a0e294000 r-xp 00000000 07:01 155 /snap/lxd/28463/lib/liblxcfs.so 2024-06-05T14:07:40.940414+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e294000-7d8a0e295000 r--p 00032000 07:01 155 /snap/lxd/28463/lib/liblxcfs.so 2024-06-05T14:07:40.940445+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e295000-7d8a0e296000 rw-p 00033000 07:01 155 /snap/lxd/28463/lib/liblxcfs.so 2024-06-05T14:07:40.940486+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e296000-7d8a0e2a4000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940530+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e2a4000-7d8a0e2cc000 r--p 00000000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940566+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e2cc000-7d8a0e461000 r-xp 00028000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940601+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e461000-7d8a0e4b9000 r--p 001bd000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940635+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4b9000-7d8a0e4ba000 ---p 00215000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940690+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4ba000-7d8a0e4be000 r--p 00215000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940726+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4be000-7d8a0e4c0000 rw-p 00219000 07:00 7471 /usr/lib/x86_64-linux-gnu/libc.so.6 2024-06-05T14:07:40.940759+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4c0000-7d8a0e4cd000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.940800+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4cd000-7d8a0e4d0000 r--p 00000000 07:00 7521 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 2024-06-05T14:07:40.940831+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4d0000-7d8a0e4e7000 r-xp 00003000 07:00 7521 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 2024-06-05T14:07:40.940891+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4e7000-7d8a0e4eb000 r--p 0001a000 07:00 7521 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 2024-06-05T14:07:40.940956+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4eb000-7d8a0e4ec000 r--p 0001d000 07:00 7521 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 2024-06-05T14:07:40.940985+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4ec000-7d8a0e4ed000 rw-p 0001e000 07:00 7521 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 2024-06-05T14:07:40.941020+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4ed000-7d8a0e4f0000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.941055+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4f0000-7d8a0e4f7000 r--p 00000000 07:01 565 /snap/lxd/28463/lib/x86_64-linux-gnu/libfuse3.so.3.10.5 2024-06-05T14:07:40.941090+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e4f7000-7d8a0e512000 r-xp 00007000 07:01 565 /snap/lxd/28463/lib/x86_64-linux-gnu/libfuse3.so.3.10.5 2024-06-05T14:07:40.941125+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e512000-7d8a0e51c000 r--p 00022000 07:01 565 /snap/lxd/28463/lib/x86_64-linux-gnu/libfuse3.so.3.10.5 2024-06-05T14:07:40.941349+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e51c000-7d8a0e52e000 r--p 0002b000 07:01 565 /snap/lxd/28463/lib/x86_64-linux-gnu/libfuse3.so.3.10.5 2024-06-05T14:07:40.941386+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e52e000-7d8a0e52f000 rw-p 0003d000 07:01 565 /snap/lxd/28463/lib/x86_64-linux-gnu/libfuse3.so.3.10.5 2024-06-05T14:07:40.941424+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e52f000-7d8a0e530000 r--p 00000000 07:01 538 /snap/lxd/28463/lib/x86_64-linux-gnu/libSegFault.so 2024-06-05T14:07:40.941469+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e530000-7d8a0e533000 r-xp 00001000 07:01 538 /snap/lxd/28463/lib/x86_64-linux-gnu/libSegFault.so 2024-06-05T14:07:40.941506+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e533000-7d8a0e534000 r--p 00004000 07:01 538 /snap/lxd/28463/lib/x86_64-linux-gnu/libSegFault.so 2024-06-05T14:07:40.941546+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e534000-7d8a0e535000 r--p 00005000 07:01 538 /snap/lxd/28463/lib/x86_64-linux-gnu/libSegFault.so 2024-06-05T14:07:40.941581+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e535000-7d8a0e536000 rw-p 00006000 07:01 538 /snap/lxd/28463/lib/x86_64-linux-gnu/libSegFault.so 2024-06-05T14:07:40.941626+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e536000-7d8a0e538000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.941687+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e538000-7d8a0e53a000 r--p 00000000 07:00 7442 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 2024-06-05T14:07:40.941724+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e53a000-7d8a0e564000 r-xp 00002000 07:00 7442 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 2024-06-05T14:07:40.941780+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e564000-7d8a0e56f000 r--p 0002c000 07:00 7442 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 2024-06-05T14:07:40.941817+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e56f000-7d8a0e570000 rw-p 00000000 00:00 0 2024-06-05T14:07:40.941852+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e570000-7d8a0e572000 r--p 00037000 07:00 7442 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 2024-06-05T14:07:40.941882+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7d8a0e572000-7d8a0e574000 rw-p 00039000 07:00 7442 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 2024-06-05T14:07:40.941975+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7ffd64ec8000-7ffd64ee9000 rw-p 00000000 00:00 0 [stack] 2024-06-05T14:07:40.942019+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7ffd64f4d000-7ffd64f51000 r--p 00000000 00:00 0 [vvar] 2024-06-05T14:07:40.942051+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: 7ffd64f51000-7ffd64f53000 r-xp 00000000 00:00 0 [vdso] 2024-06-05T14:07:40.942081+02:00 lxdvm2-x14-u17-r1 lxd.daemon[5415]: ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] ```