场景（Ubuntu 16.04）：
我编译并运行一个C程序（使用-g，我得到传统的Segmentation Fault (core dumped)，然后（当然）没有找到神话般的“核心”文件。一些挖掘说用/proc/sys/kernel/core_pattern命令修改以达到以下效果：echo '|tee /home/me/my_core_folder/my_core_file' | sudo tee /proc/sys/kernel/core_pattern，然后做完对此，我停止获取并开始只获取(core dumped)普通的Segmentation Fault.获得自动完成功能，让我到达我需要去的地方。gdb ./program_object_file.out core.pidgdb ./a.out(gdb) core core.pidtab
问题：
有没有通用的方法可以获取核心转储？我认识到我接触到的每台机器似乎都有一个迈克尔·贝的变形金刚-esque 重新配置硬件和软件的能力，这样我拥有的任何设备都不能开箱即用正常工作。是否有一个简单的算法/方法可以让我在自己的机器以及其他人的机器上找到核心转储？我总是发现自己在做了大量的工作之后就这样的事情辅导朋友，让事情为自己工作，如果能够运行命令或其他东西来将核心文件转储到运行可执行文件的目录中，那就太好了...有什么方法可以在大多数（我会满足于“某些”）Linux/Unix 机器上执行此操作吗？
答案1
这core(5)联机帮助页详细描述了影响核心转储的参数，包括它们的命名等。
为了回答您提出的问题，没有通用的方法来查找核心转储。默认情况下，核心转储到过程的当前工作目录，如果允许进程在那里写入，如果包含的文件系统上有足够的空间，如果没有现有的核心转储（在某些情况下），以及文件大小和核心文件大小限制（由ulimit或类似的机制）允许它。但/proc/sys/kernel/core_pattern提供了许多不同的处理核心转储的方法，因此您确实也需要查看并弄清楚发生了什么。
在你的情况下，我不知道为什么最初找不到核心，但我知道为什么你在设置重定向后停止获取核心：当在 中使用管道时core_pattern，处理程序必须使用绝对路径名指定。tee单独使用不会被使用；你需要指定/usr/bin/tee.请注意，您应该特别注意多用户系统上的此类设置，因为处理核心转储的程序运行为root.
在 Debian 衍生品上我安装corekeeper，它以一种易于使用的方式将核心转储写入/var/crash.
答案2
（将问题中的答案从OP移至答案）
我将下面的答案标记为正确答案，因为它帮助我确定实际出了什么问题，我想在将来返回以进一步充实这一点，但我当前的解决方案（我怀疑它适用于大多数情况） Linux 机器）是使用以下命令 -
cat /proc/sys/kernel/core_pattern > ~/.core_pattern.bak
echo '|/usr/bin/tee ~/path_you_wish_to_dump_to/core/dump' | sudo tee /proc/sys/kernel/core_pattern
这会将您以前的核心转储方法备份到.core_pattern.bak主文件夹中的隐藏文件 ( ) 中，可以使用以下命令恢复该文件
sudo cp ~/.core_pattern.bak /proc/sys/kernel/core_pattern
第二个命令将导致核心转储转储到core名为dump.显然，您可以修改此格式以获得更符合您喜好的模式。然而，应该指出的是，据我所知，这一次只会存储一个核心转储（每个新的都会破坏旧的），但因为，如果我个人检查过核心转储，它是为了刚刚运行的程序，并且由于我不需要保留旧的转储，这对我和我的朋友将要创建和调试的大多数应用程序来说是一个很好的解决方案。我很想进一步修改这个答案，以包括诸如导致段错误的PID之类的内容（主要只是顶部的糖，因为-再次-我通常知道哪个程序导致了段错误，因为我刚刚运行了它）但是这个对于我和我想象的很多人来说肯定足够了。
最后但并非最不重要的一点是，要实际查看转储，只需运行以下命令：
gdb ./executable_that_crashed ~/path_you_wish_to_dump_to/core/dump
假设您位于编译/运行出现段错误的可执行文件的文件夹中。