[systemd-devel] [ANNOUNCE] systemd v229

[Jóhann B. Guðmundsson]

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?

>
>>>          * A new service setting RuntimeMaxSec= has been added that may be used
>>>            to specify a maximum runtime for a service. If the timeout is hit, the
>>>            service is terminated and put into a failure state.
>> This does not sound right, why put it into failure state if I as an admin
>> specifically told the the service it could run for maximum X time and then
>> it should stop? ( after that time period the type unit should be stopped
>> cleanly basically systemctl stop foo.service and the state be exactly the
>> same as it yields right ? )
> I think yours appears to be a different usecase than what
> RUntimeMaxSec= currently covers.

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

jBG