Привет, @oguz. Я снова комментирую этот случай, потому что столкнулся с этой ошибкой в обновленной версии. Логи на хосте: Код: `16 мар 15:55:00 hvr2 kernel: lxcfs20228: segfault at 8018 ip 00007fcecfa6e00e sp 00007fceaf7fdaa0 error 4 in liblxcfs.so[7fcecfa5e000+14000] 16 мар 15:55:00 hvr2 kernel: Код: 41 57 41 56 41 55 41 54 53 48 81 ec d8 00 00 00 48 89 8d 38 ff ff ff 49 8b 58 18 64 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 <83> 7b 18 0 16 мар 15:55:00 hvr2 systemd1: lxcfs.service: основной процесс завершился, код=убит, статус=11/SEGV 16 мар 15:55:00 hvr2 systemd1: Запуск Runner для репликации Proxmox VE... 16 мар 15:55:00 hvr2 systemd1: var-lib-lxcfs.mount: Успешно. 16 мар 15:55:00 hvr2 systemd1: lxcfs.service: завершение с результатом 'сигнал'. 16 мар 15:55:00 hvr2 systemd1: lxcfs.service: Время ожидания перезапуска Service RestartSec=100ms истекло, запланирован перезапуск. 16 мар 15:55:00 hvr2 systemd1: lxcfs.service: Запланирована задача перезапуска, счетчик перезапусков на 1. 16 мар 15:55:00 hvr2 systemd1: Остановка файловой системы FUSE для LXC. 16 мар 15:55:00 hvr2 systemd1: Запуск файловой системы FUSE для LXC. 16 мар 15:55:00 hvr2 lxcfs27186: Запуск конструктора lxcfs_init для перезагрузки liblxcfs Код: pveversion pve-manager/6.3-6/2184247e (работающий ядро: 5.4.78-2-pve) dpkg -l |grep lxc ii lxc-pve 4.0.6-2 amd64 Инструменты пользовательского пространства для контейнеров Linux ii lxcfs 4.0.6-pve1 amd64 файловая система пользовательского пространства LXC ii pve-lxc-syscalld 0.9.1-1 amd64 демона syscall PVE LXC Можем ли мы разобраться с этой ошибкой? С уважением.

Привет, @Fabian_E, у меня снова возникла проблема (дважды) на proxmox v5, можешь всё ещё на это взглянуть? Код: ii  lxcfs-dbgsym 3.0.3-pve1 amd64 Дебаг-символы для lxcfs ii  systemd-coredump 232-25+deb9u12 amd64 инструменты для хранения и извлечения дампов памяти Как только проблема снова появится на v6, я опубликую те же сведения. С уважением.

Привет, @Fabian_E. Это случилось со мной снова несколько раз в последнее время. Я понимаю твой последний ответ, но как мы можем попытаться найти источник проблемы? Это проблематично в продуктивной среде, нам приходится останавливать контейнеры. Код: proxmox-ve: 6.4-1 (используемое ядро: 5.4.78-2-pve) pve-manager: 6.4-5 (используемая версия: 6.4-5/6c7bf5de) pve-kernel-5.4: 6.4-1 pve-kernel-helper: 6.4-1 pve-kernel-5.4.106-1-pve: 5.4.106-1 pve-kernel-5.4.103-1-pve: 5.4.103-1 pve-kernel-5.4.101-1-pve: 5.4.101-1 pve-kernel-5.4.98-1-pve: 5.4.98-1 pve-kernel-5.4.78-2-pve: 5.4.78-2 pve-kernel-5.4.73-1-pve: 5.4.73-1 ceph-fuse: 12.2.11+dfsg1-2.1+b1 corosync: 3.1.2-pve1 criu: 3.11-3 glusterfs-client: 5.5-3 ifupdown: 0.8.35+pve1 ksm-control-daemon: 1.3-1 libjs-extjs: 6.0.1-10 libknet1: 1.20-pve1 libproxmox-acme-perl: 1.0.8 libproxmox-backup-qemu0: 1.0.3-1 libpve-access-control: 6.4-1 libpve-apiclient-perl: 3.1-3 libpve-common-perl: 6.4-2 libpve-guest-common-perl: 3.1-5 libpve-http-server-perl: 3.2-1 libpve-storage-perl: 6.4-1 libqb0: 1.0.5-1 libspice-server1: 0.14.2-4~pve6+1 lvm2: 2.03.02-pve4 lxc-pve: 4.0.6-2 lxcfs: 4.0.6-pve1 novnc-pve: 1.1.0-1 proxmox-backup-client: 1.1.5-1 proxmox-mini-journalreader: 1.1-1 proxmox-widget-toolkit: 2.5-3 pve-cluster: 6.4-1 pve-container: 3.3-5 pve-docs: 6.4-1 pve-edk2-firmware: 2.20200531-1 pve-firewall: 4.1-3 pve-firmware: 3.2-2 pve-ha-manager: 3.1-1 pve-i18n: 2.3-1 pve-qemu-kvm: 5.2.0-6 pve-xtermjs: 4.7.0-3 qemu-server: 6.4-2 smartmontools: 7.2-pve2 spiceterm: 3.1-1 vncterm: 1.6-2 zfsutils-linux: 2.0.4-pve1

Привет, @oguz. Я перезагрузил сервер на недавнем ядре proxmox-ve: 6.4-1 (работающее ядро: 5.4.106-1-pve), но проблема снова возникла. У тебя есть другие идеи?

Спасибо за ответ. Можешь предоставить дамп памяти с нового краша? К сожалению, папка /var/lib/systemd/coredump пустая, и поиск файла с именем, начинающимся на 'core.lxcfs', не дает результатов, хотя пакеты установлены: Code: ii lxcfs-dbgsym 4.0.6-pve1 amd64 отладочные символы для lxcfs ii systemd-coredump 241-7~deb10u7 amd64 инструменты для хранения и извлечения дампов памяти. Есть ли у тебя идеи, почему директория /var/lib/systemd/coredump пустая? Пожалуйста, также предоставь полный вывод команды pveversion -v снова. Code: proxmox-ve: 6.4-1 (работающий ядро: 5.4.106-1-pve) pve-manager: 6.4-6 (работающая версия: 6.4-6/be2fa32c) pve-kernel-5.4: 6.4-2 pve-kernel-helper: 6.4-2 pve-kernel-5.4.114-1-pve: 5.4.114-1 pve-kernel-5.4.106-1-pve: 5.4.106-1 pve-kernel-5.4.103-1-pve: 5.4.103-1 pve-kernel-5.4.101-1-pve: 5.4.101-1 pve-kernel-5.4.98-1-pve: 5.4.98-1 pve-kernel-5.4.78-2-pve: 5.4.78-2 pve-kernel-5.4.73-1-pve: 5.4.73-1 ceph-fuse: 12.2.11+dfsg1-2.1+b1 corosync: 3.1.2-pve1 criu: 3.11-3 glusterfs-client: 5.5-3 ifupdown: 0.8.35+pve1 ksm-control-daemon: 1.3-1 libjs-extjs: 6.0.1-10 libknet1: 1.20-pve1 libproxmox-acme-perl: 1.1.0 libproxmox-backup-qemu0: 1.0.3-1 libpve-access-control: 6.4-1 libpve-apiclient-perl: 3.1-3 libpve-common-perl: 6.4-3 libpve-guest-common-perl: 3.1-5 libpve-http-server-perl: 3.2-2 libpve-storage-perl: 6.4-1 libqb0: 1.0.5-1 libspice-server1: 0.14.2-4~pve6+1 lvm2: 2.03.02-pve4 lxc-pve: 4.0.6-2 lxcfs: 4.0.6-pve1 novnc-pve: 1.1.0-1 proxmox-backup-client: 1.1.6-2 proxmox-mini-journalreader: 1.1-1 proxmox-widget-toolkit: 2.5-4 pve-cluster: 6.4-1 pve-container: 3.3-5 pve-docs: 6.4-2 pve-edk2-firmware: 2.20200531-1 pve-firewall: 4.1-3 pve-firmware: 3.2-3 pve-ha-manager: 3.1-1 pve-i18n: 2.3-1 pve-qemu-kvm: 5.2.0-6 pve-xtermjs: 4.7.0-3 qemu-server: 6.4-2 smartmontools: 7.2-pve2 spiceterm: 3.1-1 vncterm: 1.6-2 zfsutils-linux: 2.0.4-pve1. * Сколько у тебя контейнеров? И сколько из них запущено в момент краша? У нас недавние краши произошли на двух серверах, один из которых хостит 6 контейнеров, а другой 8, на остальных серверах хостятся такие же типы контейнеров, никаких особых изменений. Все контейнеры были запущены в момент краша. * Было бы полезно, если бы ты мог предоставить конфигурации контейнеров с пострадавшей машины (pct config CTID). Интересно было бы, если бы ты мог определить, какой контейнер вызывает сбой, и предоставить конфигурацию именно этого. Мы не можем определить, какой контейнер вызывает проблему больше, чем другой. Вот конфигурация pct контейнеров, которая схожа между двумя серверами. Code: arch: amd64 cores: 8 features: nesting=1 hostname: xxx memory: 6096 mp0: /apps/scripts,mp=/apps/scripts mp1: /share,mp=/share net0: name=eth3,bridge=vmbr2,hwaddr=ddd:01:2F:DC:8D,ip=yyyyy/16,type=veth net1: name=eth2,bridge=vmbr2,gw=xxx,hwaddr=eeee1:BC:EE:F2,ip=eeee/27,type=veth onboot: 1 ostype: debian rootfs: local-zfs:subvol-319-disk-0,size=20G swap: 4096 lxc.prlimit.nofile: 65536 ----- arch: amd64 cpulimit: 8 hostname: yyyy memory: 20000 mp0: /apps/scripts,mp=/apps/scripts mp1: /apps/releases,mp=/apps/releases mp2: /opt/sources,mp=/opt/sources mp3: /ftp,mp=/ftp mp4: /share,mp=/share mp5: /nfslogs,mp=/nfslogs mp6: /logs/538,mp=/logs nameserver: xxxxx net0: name=eth3,bridge=vmbr2,hwaddr=eee:F1:F1:EA,ip=xxxx/16,type=veth onboot: 1 ostype: debian rootfs: local-zfs:subvol-538-disk-0,size=15G searchdomain: vrack swap: 2048 * Как часто происходят/происходили эти краши? Это случайные события, в мае на каждом из этих двух серверов произошел по одному. Спасибо за помощь!

* Можешь выложить запись журнала с крашом, как в прошлый раз? Журнал system log Journactl не сохранялся, я только что сделал это на следующие несколько раз. * Что ты получаешь, если запустишь coredumpctl? Не найдено coredumps. * Можешь проверить и другие серверы (возможно, краш произошел на другом узле)? Оба пакета установлены на всех узлах. Поэтому мы подождем следующего краша, чтобы получить несколько логов. Быстрый вопрос: обычно у нас возникают следующие ошибки в контейнерах, когда возникает проблема: Код: Ошибка: /proc должен быть смонтирован. Чтобы смонтировать /proc при загрузке, нужна строка в /etc/fstab следующего вида: proc /proc proc defaults. Это нормально и возможно ли заново смонтировать "/proc" внутри контейнеров с помощью командной строки? Или контейнер нужно перезапустить, чтобы восстановить безопасное состояние? С уважением.

Привет, @oguz, надеюсь, у тебя всё хорошо. Я снова получил то же сообщение, у меня такие же логи в journalctl, но в coredumpctl я не вижу ничего связанного с lxcfs. Код: Jun 13 15:35:45 hvr2 kernel: lxcfs[12664]: segfault at 8018 ip 00007f389acfe00e sp 00007f38617f9aa0 error 4 in liblxcfs.so[7f389acee000+14000] Jun 13 15:40:45 hvr2 systemd[1]: lxcfs.service: Main process exited, code=killed, status=11/SEGV Jun 13 15:40:45 hvr2 systemd[1]: var-lib-lxcfs.mount: Succeeded. Jun 13 15:40:45 hvr2 systemd[1]: lxcfs.service: Failed with result 'signal'. Jun 13 15:40:45 hvr2 systemd[1]: lxcfs.service: Service RestartSec=100ms expired, scheduling restart. Jun 13 15:40:45 hvr2 systemd[1]: lxcfs.service: Scheduled restart job, restart counter is at 2. Jun 13 15:40:45 hvr2 lxcfs[17136]: Running constructor lxcfs_init to reload liblxcfs Jun 13 15:40:45 hvr2 lxcfs[17136]: mount namespace: 4 Jun 13 15:40:45 hvr2 lxcfs[17136]: hierarchies: Jun 13 15:40:45 hvr2 lxcfs[17136]: 0: fd: 5: Jun 13 15:40:45 hvr2 lxcfs[17136]: 1: fd: 6: name=systemd Jun 13 15:40:45 hvr2 lxcfs[17136]: 2: fd: 7: rdma Jun 13 15:40:45 hvr2 lxcfs[17136]: 3: fd: 8: cpuset Jun 13 15:40:45 hvr2 lxcfs[17136]: 4: fd: 9: net_cls,net_prio Jun 13 15:40:45 hvr2 lxcfs[17136]: 5: fd: 10: devices Jun 13 15:40:45 hvr2 lxcfs[17136]: 6: fd: 11: freezer Jun 13 15:40:45 hvr2 lxcfs[17136]: 7: fd: 12: cpu,cpuacct Jun 13 15:40:45 hvr2 lxcfs[17136]: 8: fd: 13: memory Jun 13 15:40:45 hvr2 lxcfs[17136]: 9: fd: 14: pids Jun 13 15:40:45 hvr2 lxcfs[17136]: 10: fd: 15: blkio Jun 13 15:40:45 hvr2 lxcfs[17136]: 11: fd: 16: perf_event Jun 13 15:40:45 hvr2 lxcfs[17136]: 12: fd: 17: hugetlb Jun 13 15:40:45 hvr2 lxcfs[17136]: Kernel supports pidfds Jun 13 15:40:45 hvr2 lxcfs[17136]: Kernel supports swap accounting Jun 13 15:40:45 hvr2 lxcfs[17136]: api_extensions: Jun 13 15:40:45 hvr2 lxcfs[17136]: - cgroups Jun 13 15:40:45 hvr2 lxcfs[17136]: - sys_cpu_online Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_cpuinfo Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_diskstats Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_loadavg Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_meminfo Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_stat Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_swaps Jun 13 15:40:45 hvr2 lxcfs[17136]: - proc_uptime Jun 13 15:40:45 hvr2 lxcfs[17136]: - shared_pidns Jun 13 15:40:45 hvr2 lxcfs[17136]: - cpuview_daemon Jun 13 15:40:45 hvr2 lxcfs[17136]: - loadavg_daemon Jun 13 15:40:45 hvr2 lxcfs[17136]: - pidfds coredumpctl : Код: Sun 2021-06-13 15:54:40 CEST 18421 0 0 6 present /usr/sbin/keepalived Sun 2021-06-13 15:54:40 CEST 18403 0 0 6 present /usr/sbin/keepalived Я думаю, что coredump от keepalived связан с остановкой/запуском виртуальной машины, которую я перезапускал, чтобы вернуть её в стабильное состояние. Не понимаю, почему у меня нет coredump, связанного с lxcfs? Есть у тебя идеи для дальнейшего изучения? С уважением.

Привет, @oguz! Спасибо за твой отзыв, вот содержание файла /etc/systemd/coredump.conf: Код: [Coredump] #Storage=external #Compress=yes #ProcessSizeMax=2G #ExternalSizeMax=2G #JournalSizeMax=767M #MaxUse= #KeepFree= Я применил обновление, но еще не перезагружал, так как в рабочей среде это сложно. Спасибо за рекомендации. Я также создал отчет о баге. С уважением.