Hi. On Mon, Feb 28, 2022 at 11:41:27AM -0500, 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 > >> > >> i had accomplished the ulimit change already, but the lack of > >> the proper permission on the output directory meant that a core > >> file would not be generated. > > > > 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: > >>>> > >>>> # core file location and file name format > >>>> kernel.core_pattern=/crash/core.%u.%E.%p > > That appears to be a kernel parameter which defines the path and > filename of the core file.
It can do that too. Quoting the relevant part of the kernel's documentation (admin-guide/sysctl/kernel.rst.gz) : If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file. For instance, one can use systemd-coredump (needs a package installed, though) to write backtraces to journald. Or, one can specify /dev/null in kernel.core_pattern, thus preventing core dumps from creating regardless of user's shell limits. > and that the syntax of the kernel parameter in question is > such that you have to specify the full path to the file. When used in such way, it's also prevents user's processes to spam an entire filesystem with coredumps. Reco