The Wanderer wrote: > On 2022-02-28 at 11:35, Greg Wooledge wrote: >> On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote: >> >>> >> me@ant(14)~$ ulimit -a >>> >> real-time non-blocking time (microseconds, -R) unlimited >>> >> core file size (blocks, -c) unlimited >>>=20 >>> i had accomplished the ulimit change already, but the lack of=20 >>> the proper permission on the output directory meant that a core >>> file would not be generated. >>=20 >> What is an "output directory"? Core files are dumped in the process's >> *working* directory, which is "where you are when you run it". > > By default, yes, that's the case. However, from songbird's original > post: > >>>>> i have the following set in my /etc/sysctl.conf: >>>>>=20 >>>>> # core file location and file name format >>>>> kernel.core_pattern=3D/crash/core.%u.%E.%p > > That appears to be a kernel parameter which defines the path and > filename of the core file.
yes! i don't know which process is crashing to cause the lockup. it is nice if all core files from crashes are located in one spot so i can find them without having to hunt for them. this may not really work if the process isn't actually dumping core, but we'll see if i can figure out which one it is. > I imagine that this was set in order to be able to specify a filename > other than the default, with relevant information about the dumping > process (and avoiding the problem of multiple such files overwriting one > another), and that the syntax of the kernel parameter in question is > such that you have to specify the full path to the file. songbird
