On Fri, Feb 24, 2023 at 08:49:59AM +0100, David Demelier wrote: > On Fri, 2023-02-24 at 05:38 +0100, Daniele Bonini wrote: > > Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > > > > > > On Mon, Feb 20, 2023 at 05:15:30PM +0100, Daniele Bonini wrote: > > > > > Is it still possible to disable file .core generation at all? > > > > > > > > > > Yes, it is. > > > > > > > > ok, thx > > > > > > > > NB: see /etc/rc.conf.local > > > > > > And also /etc/login.conf > > > > > > I did set rc.local.conf with the following: > > > > savecore_flags=-c /dev/null > > > > This is about kernel panic core dump, not userland core dumps > > > And I set login.conf adding the following: > > > > default:\ > > .. > > :coredumpsize-max=1M:\ > > :coredumpsize-cur=1M:
You can just set: :coredumpsize=0:\ to completely disable all core dump generation. > > but nothing change after a reboot, I'm always in good company > > of my 1 giga WebKitProcess.core.. > > Did you call cap_mkdb /etc/login.conf? For users who are not familar with cap_mkdb and using hashed versions of capability database files, this advice without further explanation is going to cause further confusion when they find that changes to the ascii version of the file in question suddenly 'no longer work'. You should only run cap_mkdb against a file if you're already using a database version of that file, or intend to do so from now on, in which case you'll need to run cap_mkdb after each change. For most users of small personal systems, there is no benefit to doing so and they would be better off using the ascii file directly. But then at some point they follow a random guide to something on a webpage somewhere which tells them to run cap_mkdb, and find that they mysteriously have to run it every time they edit the corresponding file afterwards. So in this case, it would have been better to ask if he has an existing /etc/login.conf.db file that needed to be updated. > You also need to login again. Presumably he has, because he said, "after a reboot".
