On Aug 6, 2019, at 7:59 AM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: > > On Tue, Aug 06, 2019 at 05:27:54AM -0600, Warren Young wrote: >> On Aug 5, 2019, at 6:57 PM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: >>> >>> no core file (yes, ulimit is configured) > > yeah, I meant "ulimit -c unlimited" is in effect. That only affects the shell it’s set for, which isn’t generally important for a service, since we no longer start services via shell scripts in the systemd world. > I had no idea systemd had made such a drastic change. This isn’t a systemd change, it’s a *system* change. The only reason systemd is involved is that it also has its own defaults, just as your shell does, overridden by the ulimit command. Steps 1-3 remove the system limits, then 4 & 5 remove the systemd limits under that, which can affect your service, if it’s being started via systemd. > or is it that > someone at RH decided to make it (nearly) impossible to do? I fail > to see how it is beneficial to anyone to make it so hard to get > core dump files. Core dumps are a security risk. They’re memory images of running processes. If you configure your server like I give in my recipe, every process that drops core will create a world-readable file in /tmp showing that process’s memory state, which means you can recover everything it was doing at the time of the crash. So, if you can find a way to make, say, PAM or sshd drop core, you’ll get live login details in debuggable form, available to anyone who can log into that box. You definitely want core dumps off by default. Making core dumps enabled by default is about as sensible as enabling rsh by default. https://en.wikipedia.org/wiki/Remote_Shell We stopped doing that on production servers about 20-30 years ago, for more or less the same reason.