On 02/11/2016 05:47 PM, Lennart Poettering wrote:
On Thu, 11.02.16 17:32, Jóhann B. Guðmundsson ([email protected]) 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
[email protected].
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
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
