我全新安装了 AlmaLinux，并且需要 Webex 用于组织聊天室。
我已经通过Webex.rpm其官方网站提供的文件安装了 Webex。
成功安装后，我尝试使用我的 Webex 电子邮件和密码登录。输入密码并单击“连接”后，Webex 窗口短暂打开并显示“正在加载”旋转器，然后立即关闭。
每次我尝试重新启动时，都会发生同样的问题。
我尝试卸载并重新安装该程序，但没有成功。
我发现了一个每次启动时都会更新的日志文件：~/home/.share/Webex/logArchive/last_run_current_log.txt，但我没有在最后一行看到错误来告诉我是什么原因导致了进程突然终止。
如果我运行，ps -ax | grep cisco我会看到一个 Cisco 进程，但 PID 一直在变化，所以它几乎就像处于一个永无止境的循环中，尝试启动、失败、尝试启动、失败等等。
到底发生了什么事？有没有人知道如何找出导致这种情况的原因，或者 - 甚至更好 - 有没有人经历过这个问题并成功解决了它？
我正在尝试分析 systemd 进程的核心转储文件，但由于缺少符号而遇到错误。
有人可以建议需要安装哪些调试符号才能成功分析这些核心转储吗？
gdb -e /usr/lib/systemd/systemd-journald -c core-systemd-journal--0-0-657-1718434887
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-20.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
warning: core file may not match specified executable file.
[New LWP 657]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Missing separate debuginfo for /lib64/libuuid.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/d0/43572678e11cfb56aecb4ec534bc016de8d0d5.debug
Missing separate debuginfo for /lib64/libudev.so.1
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/94/5e15d6b231fc346823186cd70e886dede771ca.debug
Core was generated by `/usr/lib/systemd/systemd-journald'.
Program terminated with signal SIGABRT, Aborted.
我经常使用非持久设备映射器快照，示例表如下所示：
0 10485760 snapshot /dev/sdc3 /dev/sdc6 N 16
万一发生崩溃，我仍然拥有两者/dev/sdc3，/dev/sdc6因为磁盘是非易失性的。但是是否有可能取回该snapshot设备，或者至少以某种方式恢复更改/dev/sdc6？我知道持久快照的存在是出于我的目的，但我仍然很好奇。谢谢。
崩溃以完全挂起的形式出现。没有更多的控制和屏幕冻结。
我使用以下方法在这台机器上抓取了一个堆栈跟踪：
sudo journalctl -f
最后显示的消息是：
Nov 18 19:42:12 kernel: Bad mode in Error handler detected, code 0xbf000002 -- SError
Nov 18 19:42:12 kernel: Internal error: Oops - bad mode: 0 [#3] SMP
Nov 18 19:42:12 kernel: Modules linked in: algif_hash algif_skcipher af_alg btrfs xor raid6_pq 8188fu joydev bcmdhd uio_pdrv_genirq uio binfmt_misc sch_fq_codel bnep ip_tables x_tables
Nov 18 19:42:12 kernel: CPU: 3 PID: 3469 Comm: smbd Tainted: G D W 4.4.179 #1
Nov 18 19:42:12 kernel: Hardware name: FriendlyElec NanoPi M4 (DT)
Nov 18 19:42:12 kernel: task: ffffffc0aedcd400 task.stack: ffffffc047ee8000
Nov 18 19:42:12 kernel: PC is at 0x7f78af9dfc
Nov 18 19:42:12 kernel: LR is at 0x7f78af9dd8
Nov 18 19:42:12 kernel: pc : [<0000007f78af9dfc>] lr : [<0000007f78af9dd8>] pstate: 80000000
Nov 18 19:42:12 kernel: sp : 0000007f6fbbe370
Nov 18 19:42:12 kernel: x29: 0000007f6fbbe370 x28: 00000055aa9fa870
Nov 18 19:42:12 kernel: x27: 0000007f78afc640 x26: 0000000000000000
Nov 18 19:42:12 kernel: x25: 00000055aa9fa898 x24: 0000007f6fbbe4e8
Nov 18 19:42:12 kernel: x23: 0000000000000000
Nov 18 19:42:12 kernel: Bad mode in Error handler detected, code 0xbf000002 -- SError
Nov 18 19:42:12 kernel: x22: 0000000000000000
Nov 18 19:42:12 kernel:
Nov 18 19:42:12 kernel: x21: 00000055aa9fa898 x20: 0000000000000000
Nov 18 19:42:12 kernel: x19: 0000000000000189 x18: 0000000000000001
Nov 18 19:42:12 kernel: x17: 0000000000000002 x16: 0000000000000002
Nov 18 19:42:12 kernel: x15: 0000000000000000 x14: 002ffa52590473c3
Nov 18 19:42:12 kernel: x13: 0000000063784283 x12: 0000000000000018
Nov 18 19:42:12 kernel: x11: 000000003006b4dc x10: 0000000063784283
Nov 18 19:42:12 kernel: x9 : 003b9aca00000000 x8 : 0000000000000062
Nov 18 19:42:12 kernel: x7 : 0000007f6fbbe448 x6 : 0000000000000000
Nov 18 19:42:12 kernel: x5 : 00000000ffffffff x4 : 0000000000000000
Nov 18 19:42:12 kernel: x3 : 0000007f6fbbe4e8 x2 : 0000000000000000
Nov 18 19:42:12 kernel: x1 : 0000000000000189 x0 : 0000000000000000
Nov 18 19:42:12 kernel:
Nov 18 19:42:12 kernel: Process smbd (pid: 3469, stack limit = 0xffffffc047ee8000)
Nov 18 19:42:12 kernel: ---[ end trace 5fba866947145e9b ]---
Nov 18 19:42:12 kernel: Bad mode in Error handler detected, code 0xbf000002 -- SError
Nov 18 19:42:12 kernel: Internal error: Oops - bad mode: 0 [#4] SMP
Nov 18 19:42:12 kernel: Modules linked in: algif_hash algif_skcipher af_alg btrfs xor raid6_pq 8188fu joydev bcmdhd uio_pdrv_genirq uio binfmt_misc sch_fq_codel bnep ip_tables x_tables
Nov 18 19:42:12 kernel: CPU: 5 PID: 3471 Comm: smbd Tainted: G D W 4.4.179 #1
Nov 18 19:42:12 kernel: Hardware name: FriendlyElec NanoPi M4 (DT)
Nov 18 19:42:12 kernel: task: ffffffc0b72c8000 task.stack: ffffffc047d40000
Nov 18 19:42:12 kernel: PC is at 0x7f78af9dfc
Nov 18 19:42:12 kernel: LR is at 0x7f78af9dd8
Nov 18 19:42:12 kernel: pc : [<0000007f78af9dfc>] lr : [<0000007f78af9dd8>] pstate: 80000000
Nov 18 19:42:12 kernel: sp : 0000007f7240e370
Nov 18 19:42:12 kernel: x29: 0000007f7240e370 x28: 00000055aa9fa870
Nov 18 19:42:12 kernel: x27: 0000007f78afc640 x26: 0000000000000000
Nov 18 19:42:12 kernel: x25: 00000055aa9fa898 x24: 0000007f7240e4e8
Nov 18 19:42:12 kernel: x23: 0000000000000000 x22: 0000000000000000
Nov 18 19:42:12 kernel: x21: 00000055aa9fa898 x20: 0000000000000000
Nov 18 19:42:12 kernel: x19: 0000000000000189 x18: 0000000000000000
Nov 18 19:42:12 kernel: x17: 0000000000000004 x16: 0000000000000002
Nov 18 19:42:12 kernel: x15: 0000000000000000 x14: 00302818e1b6bcc3
Nov 18 19:42:12 kernel: x13: 0000000063784283 x12: 0000000000000018
Nov 18 19:42:12 kernel: x11: 0000000030366a81 x10: 0000000063784283
Nov 18 19:42:12 kernel: x9 : 003b9aca00000000 x8 : 0000000000000062
Nov 18 19:42:12 kernel: x7 : 0000007f7240e448 x6 : 0000000000000000
Nov 18 19:42:12 kernel: x5 : 00000000ffffffff x4 : 0000000000000000
Nov 18 19:42:12 kernel: x3 : 0000007f7240e4e8 x2 : 0000000000000000
Nov 18 19:42:12 kernel: x1 : 0000000000000189 x0 : 0000000000000000
Nov 18 19:42:12 kernel:
Nov 18 19:42:12 kernel: Process smbd (pid: 3471, stack limit = 0xffffffc047d40000)
Nov 18 19:42:12 kernel: ---[ end trace 5fba866947145e9c ]---
Nov 18 19:42:12 kernel: Internal error: Oops - bad mode: 0 [#5] SMP
大量访问 nvme 驱动器时似乎会发生这种情况，但这可能只是与问题有关。我进入 hdparm 并尝试关闭许多驱动器功能，但错误仍然存在。
我还尝试过更改 CPU 的时钟速度和电源。这些影响不大
精简版：
如果其中一个池已分配，则使用systemctl start libvirtd（或者libvirtd.service，似乎具有相同的效果？）会在没有警告的情况下使系统崩溃。/dev
长版：
我正在尝试在 Archlinux 上的 passthrough 的帮助下使用virt-manager. 我正在遵循本指南。在配置虚拟机部分，第一步是添加存储，然后选择/dev. 一旦我这样做了，系统将在大约 1 分钟后立即重启，没有任何警告。我systemctl status libvirtd定期检查过，我看到的最短时间是55秒；我从来没有看到1分钟。设置保存在/etc/libvirt/storage/pool*.xml( pool-1.xml，或类似的东西)。我同时删除了它，现在没有更多的崩溃了。reddit 上有一个和两个线程，但没有任何解决方法。
这是一种已知的行为，还是一种怪癖？如何绕过它并完成安装来宾操作系统？
从 Debian 10 切换到 11 后，LibreOffice Draw 7.0 无法再打开。
我尝试打开一个现有文件并启动一个新文件，无论我如何打开 Draw，它都会崩溃并显示以下消息：
Due to an error, LibreOffice crashed. All the files you were working on will now be saved.
Next time the LibreOffice is launched, your files will be recovered automatically.
如果我打开一个现有文件，或者尝试创建一个新文件，它会崩溃，然后立即尝试为空白文件提取文档恢复，然后再次崩溃，无论我选择哪种打开方式。
Please ensure that a JVM and the package libreoffice-java-common
is installed.
If it is already installed then try removing ~/.config/libreoffice/4/user/config/javasettings_Linux_*.xml
Warning: failed to read path from javaldx
(soffice:4787): dbind-WARNING **: 14:29:52.992: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
我尝试了几件事：
.config与 LibreOffice 相关的文件。libreoffice-gtk3（有人说没有安装它会崩溃）。如何修复 LibreOffice Draw 崩溃？
更新：
journalctl每次我尝试打开 Draw 时都会报告此问题，但在打开有效的工具时不会报告，例如 Write：
Jul 08 15:35:20 debian audit[2833]: AVC apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" name="/home/village/Projects/Textbooks/Popups/Core/2022-07-05_glossary.data" pid=2833 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Jul 08 15:35:20 debian kernel: audit: type=1400 audit(1657316120.083:15): apparmor="ALLOWED" operation="open"
更新：
我发现如果我运行libreoffce --norestore以禁用崩溃处理，它会打印此错误：
Fatal exception: Signal 6
堆：
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x3dc53)[0x7f3a8d719c53]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x3ddc2)[0x7f3a8d719dc2]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bd60)[0x7f3a8d547d60]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f3a8d547ce1]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7f3a8d531537]
/usr/lib/libreoffice/program/libmergedlo.so(+0x1188b91)[0x7f3a8e8cab91]
/usr/lib/libreoffice/program/libmergedlo.so(+0x2255cf0)[0x7f3a8f997cf0]
/usr/lib/libreoffice/program/libmergedlo.so(+0x32fcfb9)[0x7f3a90a3efb9]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x17412)[0x7f3a8d6f3412]
/usr/lib/libreoffice/program/libuno_sal.so.3(+0x3dd2f)[0x7f3a8d719d2f]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bd60)[0x7f3a8d547d60]
我在 Ubuntu 16 VM 上安装了 Kodi 16.1，但它已停止工作。它在刮电视时经常崩溃。
我已经删除~/.kodi并且它可以正常工作，但是一旦我添加回来advancedsettings.xml并将其指向我的电视目录，它就崩溃了。
奇怪的是，它能够很好地抓取我的电影库，只有电视会导致问题。
这是一些日志，它是 7MB 的日志，所以我修剪了一些东西。任何想法可能是什么问题？
############## Kodi CRASH LOG ###############
################ SYSTEM INFO ################
Date: Sat Aug 3 04:38:57 PDT 2019
Kodi Options:
Arch: x86_64
Kernel: Linux 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016
Release: Ubuntu 16.04.5 LTS (Xenial Xerus)
############## END SYSTEM INFO ##############
############### STACK TRACE #################
=====> Core file: /home/sysadmin/core (2019-08-03 04:38:57.897997384 -0700)
=========================================
[New LWP 2892]
[New LWP 2857]
[New LWP 2859]
[New LWP 2860]
[New LWP 2862]
[New LWP 2866]
[New LWP 2867]
[New LWP 2868]
[New LWP 2869]
[New LWP 2871]
[New LWP 2873]
[New LWP 2875]
[New LWP 2876]
[New LWP 2877]
[New LWP 2878]
[New LWP 2879]
[New LWP 2880]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/kodi/kodi.bin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f129c372bbc in _int_malloc (av=av@entry=0x7f1254000020, bytes=bytes@entry=79) at malloc.c:3353
[Current thread is 1 (Thread 0x7f1286542700 (LWP 2892))]
Thread 17 (Thread 0x7f124dffb700 (LWP 2880)):
#0 0x00007f129c3ee5d3 in select () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000000001044936 in JSONRPC::CTCPServer::Process() ()
#2 0x0000000001d2ac6f in CThread::Action() ()
#3 0x0000000001d2af2f in CThread::staticThread(void*) ()
#4 0x00007f12a26866ba in start_thread (arg=0x7f124dffb700) at pthread_create.c:333
#5 0x00007f129c3f841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 16 (Thread 0x7f124e7fc700 (LWP 2879)):
#0 0x00007f129c3ee5d3 in select () at ../sysdeps/unix/syscall-template.S:84
#1 0x00000000010429bc in SOCKETS::CSocketListener::Listen(int) ()
#2 0x000000000103689e in EVENTSERVER::CEventServer::Run() ()
#3 0x0000000001036b48 in EVENTSERVER::CEventServer::Process() ()
#4 0x0000000001d2ac6f in CThread::Action() ()
#5 0x0000000001d2af2f in CThread::staticThread(void*) ()
#6 0x00007f12a26866ba in start_thread (arg=0x7f124e7fc700) at pthread_create.c:333
#7 0x00007f129c3f841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
更新：看起来问题与 TVDB.com API 更改和插件更新有关。无论如何都会发布此线程并在修复时进行更新，但我的安装并没有出现任何问题。
我一直在凌晨发生系统崩溃。00:00 至 08:00 之间。
查看日志，看起来每个核心都慢了下来，最终崩溃，直到整个系统冻结。从第一个错误到系统崩溃大约需要 25 分钟。这些错误让我想到了内存问题，但我不确定这是否只是因为其他一些故障。
该系统是具有双 E5-2630 V2 和 16X 8GB DDR3 的 Super Micro X9DRW-IF
操作系统是 Proxmox 最新的
核心：
Linux pve1 4.15.18-10-pve #1 SMP PVE 4.15.18-32 (Sat, 19 Jan 2019)
PERF 中断开始花费越来越长的时间，并且内存错误开始发生。在系统在 20 分钟到 1 小时内冻结之前，大约会出现 20 个此类错误。据我了解，PERF 只是 CPU 节流。它会限制到尽可能低的速度，此时系统会爬行。
Apr 28 07:36:05 pve1 kernel: [36497.018818] perf: interrupt took too long (6737393 > 4247631), lowering kernel.perf_event_max_sample_rate to 250
Apr 28 07:36:05 pve1 kernel: [36497.018914] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
Apr 28 07:36:05 pve1 kernel: [36497.018926] {1}[Hardware Error]: It has been corrected by h/w and requires no further action
Apr 28 07:36:05 pve1 kernel: [36497.019012] {1}[Hardware Error]: event severity: corrected
Apr 28 07:36:05 pve1 kernel: [36497.019112] {1}[Hardware Error]: Error 0, type: corrected
Apr 28 07:36:05 pve1 kernel: [36497.019115] {1}[Hardware Error]: fru_text: CorrectedErr
Apr 28 07:36:05 pve1 kernel: [36497.019119] {1}[Hardware Error]: section_type: memory error
Apr 28 07:36:05 pve1 kernel: [36497.019125] {1}[Hardware Error]: node: 1 device: 0
Apr 28 07:36:05 pve1 kernel: [36497.019128] {1}[Hardware Error]: error_type: 2, single-bit ECC
Apr 28 07:36:05 pve1 kernel: [36497.019297] ghes_edac: Internal error: Can't find EDAC structure
Apr 28 07:36:06 pve1 pve-firewall[2311]: firewall update time (13.994 seconds)
Apr 28 07:36:10 pve1 kernel: [36502.054892] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 451.489 msecs
Apr 28 07:36:17 pve1 pve-firewall[2311]: firewall update time (9.985 seconds)
Apr 28 07:36:20 pve1 pvestatd[2315]: got timeout
Apr 28 07:36:26 pve1 pvestatd[2315]: status update time (33.041 seconds)
Apr 28 07:36:28 pve1 pve-firewall[2311]: firewall update time (11.073 seconds)
Apr 28 07:36:50 pve1 kernel: [36542.038771] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 451.686 msecs
Apr 28 07:36:56 pve1 pve-firewall[2311]: firewall update time (27.943 seconds)
Apr 28 07:36:56 pve1 pvestatd[2315]: status update time (30.979 seconds)
Apr 28 07:37:03 pve1 pve-firewall[2311]: firewall update time (6.031 seconds)
在这一点上，我只想了解实际发生的情况。
在 Centos 7 下，mate-power-manager（来自 EPEL repo）不断崩溃。从命令行手动运行时，在崩溃时会引发错误：
ERROR:gpm-kbd-backlight.c:342:gpm_kbd_backlight_on_dbus_signal: code should not be reached
我发现它与 不兼容upower，解决方法建议减少崩溃，但不要消除它。
它已在1.18.1 版本中修复， 但在 EPEL 中不可用。我已经尝试自己构建它，但不断收到 sudo 提示
authentication is needed to run mate-power-backlight-helper
我真的只想mate-power-manager继续运行（或在崩溃后自动重启），这样我就不会错过严重的电池警报。
在广泛抱怨之后，ext4 获得了auto_da_alloc默认启用的碰撞安全保证。其他文件系统呢？在最著名的文件系统中，哪些提供相同的保证（哪些不提供）？
就我个人而言，我有兴趣听到关于
根据下面的历史，这个问题主要与 Linux 有关。了解 ZFS 的行为方式也会很有趣，但我倾向于假设它不会实现这一点。
auto_da_alloc？fsync() 被详细记录为写入文件数据的正确方法，例如当您在文本编辑器中点击“保存”时。众所周知，例如文本编辑器必须使用 rename() 原子地替换现有文件。这是为了防止断电，确保您始终保留旧文件或获取新文件（在重命名之前已 fsync()ed）。您不希望只留下新文件的半写版本。
但是有一个问题是，在最流行的 Linux 文件系统 ext3 上调用 fsync() 可以有效地使整个系统挂起数十秒。由于应用程序对此无能为力，因此乐观地使用 rename() 而不使用 fsync() 是很常见的。即使系统断电，这种模式似乎在这个文件系统上运行得相当好。
因此，存在不正确使用 fsync() 的应用程序。
文件系统的下一个版本 ext4 通常避免了 fsync() 挂起。同时，它开始更多地依赖于 fsync() 的正确使用。
这一切都很糟糕。许多相互冲突的内核开发人员使用的不屑一顾的短语可能无助于理解这段历史。
这在 ext4 中得到了解决，到支持 rename() 模式，而不需要 fsync() 来确保崩溃安全提供崩溃时的行为，就像旧的 ext3 文件系统一样。如果您使用选项挂载，则可以再次禁用此行为noauto_da_alloc。