[systemd-devel] [ANNOUNCE] systemd v229

[Lennart Poettering]

On Thu, 11.02.16 19:08, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:

> 
> 
> On 02/11/2016 05:47 PM, Lennart Poettering wrote:
> >On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson (johannbg at gmail.com) wrote:
> >
> >>>I just tagged the v229 release of systemd. Enjoy!
> >>>
> >>>CHANGES WITH 229:
> >>>
> >>>         * The coredump collection logic has been reworked: when a coredump is
> >>>           collected it is now written to disk, compressed and processed
> >>>           (including stacktrace extraction) from a new instantiated service
> >>>           systemd-coredump at .service.
> >>Is it enough to disable this type service unit to completely disable
> >>coredump or will users have to for example set Storage=none in coredump.conf
> >>and or other tweaks and if so which ones?
> >Try the man page systemd-coredump(8), first paragraph.
> 
> I do believe that's not enough to completely disable this and confusing at
> best I mean is the man page refering to /usr/lib/sysctl.d/50-coredump.conf
> or /etc/systemd/coredump.conf which is what the administrator would
> associate this with since you know he was reading that particular man page.
> 
> There is a quite the difference of doing "ln -s /dev/null
> /etc/sysctl.d/50-coredump.conf && sysctl -p or /lib/systemd/systemd-sysctl"
> if systemd does not pick up the sysctl changes
> vs administrators creating a symlink to /etc/systemd/coredump.conf disable
> this and run systemctl daemon-reload while the former is probably what's
> being refereed to.
> 
> And based on how that got implemented I have to ask cant this be disable
> completely as a switch in /etc/systemd/coredump.conf without having to have
> administrators jump through hoops, create symlinks and what not?

You can also set Storage=none, if you like. In this case we'll log
about the coredump, but not store it.

> What's the usecase you had in mind and why leave it in failed state?

Because something is weird about it as normally it shouldn't take that long...

Lennart

-- 
Lennart Poettering, Red Hat